From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Julian Graham" Newsgroups: gmane.lisp.guile.devel Subject: Re: srfi-18 requirements Date: Tue, 19 Feb 2008 21:10:10 -0500 Message-ID: <2bc5f8210802191810v729d8fa5jec070d3ee4358493@mail.gmail.com> References: <2bc5f8210710101854m1254160ei451026182b87e767@mail.gmail.com> <2bc5f8210801241738j25c594wfc347b337aa7ed47@mail.gmail.com> <2bc5f8210801271806o478f2e24u1bbc77a21a270d5a@mail.gmail.com> <87abmig9v5.fsf@ossau.uklinux.net> <2bc5f8210802042227p7a2cb926ge64414c3665082dd@mail.gmail.com> <87fxw55zm0.fsf@ossau.uklinux.net> <871w7os5gn.fsf@ossau.uklinux.net> <2bc5f8210802071604s2519d5c5qa6035426de62f29@mail.gmail.com> <2bc5f8210802102114m4eab895dr3114b7ea74156b38@mail.gmail.com> <87pruso94g.fsf@ossau.uklinux.net> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1203473429 18525 80.91.229.12 (20 Feb 2008 02:10:29 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 20 Feb 2008 02:10:29 +0000 (UTC) Cc: =?ISO-8859-1?Q?Ludovic_Court=E8s?= , guile-devel@gnu.org To: "Neil Jerram" Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Wed Feb 20 03:10:51 2008 Return-path: Envelope-to: guile-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1JReQ5-0006Vn-IU for guile-devel@m.gmane.org; Wed, 20 Feb 2008 03:10:49 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1JRePa-0006hx-Jk for guile-devel@m.gmane.org; Tue, 19 Feb 2008 21:10:18 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1JRePX-0006eM-Al for guile-devel@gnu.org; Tue, 19 Feb 2008 21:10:15 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1JRePW-0006cw-Gn for guile-devel@gnu.org; Tue, 19 Feb 2008 21:10:15 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1JRePW-0006cO-Aj for guile-devel@gnu.org; Tue, 19 Feb 2008 21:10:14 -0500 Original-Received: from fk-out-0910.google.com ([209.85.128.184]) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1JRePV-0006bT-NZ for guile-devel@gnu.org; Tue, 19 Feb 2008 21:10:14 -0500 Original-Received: by fk-out-0910.google.com with SMTP id 26so2857670fkx.10 for ; Tue, 19 Feb 2008 18:10:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=ALDJx2hbtZiyUgHM7QBMfA4WHKDvqdMYO/8ZCCRYewc=; b=j3isz8BwLBTaoWZdfr3DAIxV+g5Iqy/dN9GCKbynQT0er6NbX/aqX+fmXKItHgGW8BbjhGDBVK086Iq9H26c9lQtC0wavQ/aIpR6Kpms/bifDXKdEX3yjwDwPcv2+6DEbKQ/kPwd12yEUCU9CQTn9R+IzHe8G6FYjVJFZD9xTbk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=L8QF0kVNOop6e4eZGw/WBV9oBvDAVVkTuq6RjOYNFfpI58w3SzQ4CwdxYbfw3XSIF9tHzb4qDpvCxVKfiMD9HO7XiTuyD+Trr6ZPLMyoHprHEIrQT7vri5FmPoNUrmaL1j/HR1+6GR6j/AS3ZYWG587KyZcmNEFrYXeO7f1nSnM= Original-Received: by 10.82.140.20 with SMTP id n20mr15596211bud.24.1203473410965; Tue, 19 Feb 2008 18:10:10 -0800 (PST) Original-Received: by 10.82.100.9 with HTTP; Tue, 19 Feb 2008 18:10:10 -0800 (PST) In-Reply-To: <87pruso94g.fsf@ossau.uklinux.net> Content-Disposition: inline X-detected-kernel: by monty-python.gnu.org: Linux 2.6 (newer, 2) X-BeenThere: guile-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Developers list for Guile, the GNU extensibility library" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Errors-To: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.lisp.guile.devel:7033 Archived-At: Hi Neil, > Looking good! Many thanks for your continuing work on this, and sorry > for my delay (once again!) in reviewing. I have a few comments, as > follows. No worries. Find my responses below. > > @c begin (texi-doc-string "guile" "join-thread") > > -@deffn {Scheme Procedure} join-thread thread > > +@deffn {Scheme Procedure} join-thread thread [timeout] > > @deffnx {C Function} scm_join_thread (thread) > > +@deffnx {C Function} scm_join_thread_timed (thread, timeout) > > Didn't we agree to add a timeout-val parameter here? No, we didn't, although I agree such a parameter would be pretty useful. I'll add that in the next revision I send you. > > +static scm_t_timespec > > +scm_to_timespec (SCM t) > > For static functions it's nice to omit the scm_ prefix, because they > don't need it, and it makes it clearer to the casual reader that > they're not part of the API. > > Also, can the signature be void to_timespec (SCM t, scm_t_timespec *), > to avoid relying on support for struct return? Yes and yes. > > + else if (!first_iteration) > > + { > > + if (timeout != NULL) > > + { > > + gettimeofday (¤t_time, NULL); > > + if (current_time.tv_sec > timeout->tv_sec || > > + (current_time.tv_sec == timeout->tv_sec && > > + current_time.tv_usec * 1000 > timeout->tv_nsec)) > > + { > > + *ret = 0; > > + break; > > + } > > Is timeout an absolute time, or relative to when join-thread was > called? Before getting to this code, I thought it was relative - but > then I don't see how the code above can be correct, because it is > comparing against the absolute gettimeofday() ...? It's absolute -- like the arguments for the existing timed synchronization primitives (and like the timed parts of the SRFI-18 API). (Unless I'm mistaken...) > > -static char * > > -fat_mutex_unlock (fat_mutex *m) > > +static void > > +fat_mutex_unlock (SCM mx) > > { > > - char *msg = NULL; > > - > > + fat_mutex *m = SCM_MUTEX_DATA (mx); > > scm_i_scm_pthread_mutex_lock (&m->lock); > > - if (!scm_is_eq (m->owner, scm_current_thread ())) > > + if (m->level > 0) > > + m->level--; > > + else > > It looks like there is a significant change to the semantics here: any > thread can unlock a mutex, not just the thread that locked it. Is > that the intention, or am I misunderstanding? No, that's the intention (it's explicitly permitted by SRFI-18). I thought you were okay with that, since it was not on your list of stuff that didn't belong in C. If that's too big of a change, might I suggest we add a function that forcibly unlocks a mutex, regardless of the owner? > Actually, that strongly says to me that we don't need the `cond' part > of this API to be implemented in C. Can we move that to the SRFI-18 > Scheme code, and leave the C API as a plain unlock-mutex operation? Fine by me (again. left this one in because you didn't squawk about it earlier), except that it might be harder to guarantee the safety of mixing the mutex and cond passed to the SRFI-18 Scheme implementation with non-SRFI-18 calls -- C generally provides a convenient protection against deadlock for things like that. Regards, Julian