From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Neil Jerram Newsgroups: gmane.lisp.guile.devel Subject: Re: srfi-18 requirements Date: Sat, 08 Mar 2008 16:34:37 +0000 Message-ID: <87bq5pb2ea.fsf@ossau.uklinux.net> References: <2bc5f8210710101854m1254160ei451026182b87e767@mail.gmail.com> <2bc5f8210802071604s2519d5c5qa6035426de62f29@mail.gmail.com> <2bc5f8210802102114m4eab895dr3114b7ea74156b38@mail.gmail.com> <87pruso94g.fsf@ossau.uklinux.net> <2bc5f8210802191810v729d8fa5jec070d3ee4358493@mail.gmail.com> <87r6f5zv6t.fsf@ossau.uklinux.net> <2bc5f8210802212014o45a9c79dpd688f11726a1e159@mail.gmail.com> <87ir0e1yka.fsf@ossau.uklinux.net> <2bc5f8210802241017o46468365j33c329a069d96d33@mail.gmail.com> <873ariaq82.fsf@ossau.uklinux.net> <2bc5f8210803011156i3bfb976bsda2a7902654ba3a6@mail.gmail.com> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1204994105 8884 80.91.229.12 (8 Mar 2008 16:35:05 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 8 Mar 2008 16:35:05 +0000 (UTC) Cc: =?iso-8859-1?Q?Ludovic_Court=E8s?= , guile-devel@gnu.org To: "Julian Graham" Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Sat Mar 08 17:35:32 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 1JY21B-00034U-Cw for guile-devel@m.gmane.org; Sat, 08 Mar 2008 17:35:29 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1JY20d-00083Z-K1 for guile-devel@m.gmane.org; Sat, 08 Mar 2008 11:34:55 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1JY20Z-0007zT-Nv for guile-devel@gnu.org; Sat, 08 Mar 2008 11:34:51 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1JY20U-0007oA-KG for guile-devel@gnu.org; Sat, 08 Mar 2008 11:34:51 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1JY20T-0007nP-VO for guile-devel@gnu.org; Sat, 08 Mar 2008 11:34:46 -0500 Original-Received: from mail3.uklinux.net ([80.84.72.33]) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1JY20N-00060y-Qd; Sat, 08 Mar 2008 11:34:40 -0500 Original-Received: from arudy (host86-145-183-175.range86-145.btcentralplus.com [86.145.183.175]) by mail3.uklinux.net (Postfix) with ESMTP id 56A151F7A14; Sat, 8 Mar 2008 16:34:38 +0000 (GMT) Original-Received: from laruns (laruns [192.168.0.10]) by arudy (Postfix) with ESMTP id B5BE03800A; Sat, 8 Mar 2008 16:34:37 +0000 (GMT) In-Reply-To: <2bc5f8210803011156i3bfb976bsda2a7902654ba3a6@mail.gmail.com> (Julian Graham's message of "Sat, 1 Mar 2008 14:56:07 -0500") User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/21.4 (gnu/linux) X-detected-kernel: by monty-python.gnu.org: Linux 2.4-2.6 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:7066 Archived-At: "Julian Graham" writes: > Find attached the latest revision of the core changes for SRFI-18 > support. Key changes between this revision and the last are: > > * scm_to_timespec -> to_timespec > * "Timeout values" for timed joins > * The extension of make-mutex and addition of make_mutex_with_flags to > support additional configuration options that persist for the lifetime > of a mutex (unchecked unlocking and external unlocking) > * fat_mutex_unlock now takes a condition variable and a timeout to > support SRFI-18's condition-signal unlock semantics; mutex unlocking > and condition variable waiting are reimplemented in terms of > fat_mutex_unlock; unnecessary relocking / unlocking is no longer > performed > * The threads tests and scheduling documentation have been updated to > reflect the above. > > Let me know what you think! It looks great. I still have a few minor queries, but it's close enough now that I've committed this latest patch to CVS; it'll be much more convenient to work on the few remaining queries incrementally, rather than with respect to threads.c as it was prior to all these changes. > -@deffn {Scheme Procedure} make-mutex > +@deffn {Scheme Procedure} make-mutex . flags > @deffnx {C Function} scm_make_mutex () > -Return a new standard mutex. It is initially unlocked. > +@deffnx {C Function} scm_make_mutex_with_flags (SCM flag) flag -> flags here? > +static void > +to_timespec (SCM t, scm_t_timespec *waittime) > +{ > + if (scm_is_pair (t)) > + { > + waittime->tv_sec = scm_to_ulong (SCM_CAR (t)); > + waittime->tv_nsec = scm_to_ulong (SCM_CDR (t)) * 1000; > + } > + else > + { > + double time = scm_to_double (t); > + double sec = scm_c_truncate (time); > + > + waittime->tv_sec = (long) sec; > + waittime->tv_nsec = (long) ((time - sec) * 1000000); 1000000 -> 1000000000 ? > +static SCM unchecked_unlock_sym; > +static SCM allow_external_unlock_sym; > +static SCM recursive_sym; Use SCM_SYMBOL here? As the init code stands, this means that the symbols will end up being created in scm_init_thread_procs(), but I think that will be fine, as the symbols are only useful in procedure calls. > + > +SCM_DEFINE (scm_make_mutex_with_flags, "make-mutex", 0, 0, 1, > + (SCM flags), > "Create a new mutex. ") > -#define FUNC_NAME s_scm_make_mutex > +#define FUNC_NAME s_scm_make_mutex_with_flags > { > - return make_fat_mutex (0); > + int unchecked_unlock = 0, external_unlock = 0, recursive = 0; > + > + SCM ptr = flags; > + while (! scm_is_null (ptr)) > + { > + SCM flag = SCM_CAR (ptr); > + if (scm_is_eq (flag, unchecked_unlock_sym)) > + unchecked_unlock = 1; > + else if (scm_is_eq (flag, allow_external_unlock_sym)) > + external_unlock = 1; > + else if (scm_is_eq (flag, recursive_sym)) > + recursive = 1; > + else > + SCM_MISC_ERROR ("unsupported mutex option", SCM_EOL); Perhaps we can generate a more explicit error here, indicating the actual problem value? See other calls to scm_misc_error() where the 3rd parameter is not SCM_EOL. > +static int > +fat_mutex_unlock (SCM mutex, SCM cond, > + const scm_t_timespec *waittime, int relock) > { > - char *msg = NULL; > + fat_mutex *m = SCM_MUTEX_DATA (mutex); > + fat_cond *c = NULL; > + scm_i_thread *t = SCM_I_CURRENT_THREAD; > + int err = 0, ret = 0; > > scm_i_scm_pthread_mutex_lock (&m->lock); > if (!scm_is_eq (m->owner, scm_current_thread ())) > { > if (scm_is_false (m->owner)) > - msg = "mutex not locked"; > - else > - msg = "mutex not locked by current thread"; > + { > + if (!m->unchecked_unlock) > + scm_misc_error (NULL, "mutex not locked", SCM_EOL); > + } > + else if (!m->allow_external_unlock) > + scm_misc_error (NULL, "mutex not locked by current thread", SCM_EOL); > + } Need to unlock m->lock before raising the error? > SCM_DEFINE (scm_timed_wait_condition_variable, "wait-condition-variable", 2, 1, 0, > @@ -1393,20 +1590,11 @@ > > if (!SCM_UNBNDP (t)) > { > - if (scm_is_pair (t)) > - { > - waittime.tv_sec = scm_to_ulong (SCM_CAR (t)); > - waittime.tv_nsec = scm_to_ulong (SCM_CAR (t)) * 1000; > - } > - else > - { > - waittime.tv_sec = scm_to_ulong (t); > - waittime.tv_nsec = 0; > - } > + to_timespec (t, &waittime); > waitptr = &waittime; > } > > - return scm_from_bool (fat_cond_timedwait (cv, mx, waitptr)); > + return fat_cond_timedwait (cv, mx, waitptr) ? SCM_BOOL_T : SCM_BOOL_F; Better to eliminate fat_cond_timedwait completely now, I think. (i.e. Just rewrite the last line as a fat_mutex_unlock() call.) Finally, please note that we will need a NEWS entry for this work. Are you happy to write that too? (You may of course prefer to defer this until the SRFI-18 Scheme parts are committed too - that's absolutely fine.) Regards, Neil