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: Mon, 26 Nov 2007 13:11:14 -0500 Message-ID: <2bc5f8210711261011l705c866pe446b4e4a76edf79@mail.gmail.com> References: <2bc5f8210710101854m1254160ei451026182b87e767@mail.gmail.com> <87lka8pvv3.fsf@laas.fr> <2bc5f8210710120831q5c90dcfes930595fa3eb16a77@mail.gmail.com> <2bc5f8210710151526t6345200ao997988c1877e8cce@mail.gmail.com> <4713EB20.3080608@member.fsf.org> <2bc5f8210710151547l5e245ed1ucaf07e9006e95387@mail.gmail.com> <2bc5f8210710290737j32fe7b1s86aaa7e084bb69b6@mail.gmail.com> 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 1196100708 27782 80.91.229.12 (26 Nov 2007 18:11:48 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 26 Nov 2007 18:11:48 +0000 (UTC) To: guile-devel@gnu.org Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Mon Nov 26 19:11:54 2007 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 1IwiR0-00071D-62 for guile-devel@m.gmane.org; Mon, 26 Nov 2007 19:11:54 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1IwiQl-0007sd-1v for guile-devel@m.gmane.org; Mon, 26 Nov 2007 13:11:39 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1IwiQS-0007mf-Ti for guile-devel@gnu.org; Mon, 26 Nov 2007 13:11:20 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1IwiQR-0007m5-2I for guile-devel@gnu.org; Mon, 26 Nov 2007 13:11:20 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1IwiQQ-0007lx-Rg for guile-devel@gnu.org; Mon, 26 Nov 2007 13:11:18 -0500 Original-Received: from nf-out-0910.google.com ([64.233.182.186]) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1IwiQQ-0007AM-61 for guile-devel@gnu.org; Mon, 26 Nov 2007 13:11:18 -0500 Original-Received: by nf-out-0910.google.com with SMTP id f5so770618nfh for ; Mon, 26 Nov 2007 10:11:15 -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:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=O1f6TSo5/IyCjds/Pd+Qg9P3Pnz8QJXA3V0usnlhWTA=; b=C2T9JmloGI2sxykgGlyoXQIPHkr7+px6lGZn7PFpIY7nDtTdEAGolHmApN1vYcigzIf/Yy5B8mzr74e8QTUz3fSXVp9i4RmLsSGpPjmJrv2cpi+sLj0e/HtlRH+8fFDNB4s811CBztcRUylTZl4e7T8vIVhhJvv6PyV/zwg1reU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=MeA24V6LyfrLmAL9Ji7EgkPKNbTI2xeQY409G51bMb67l6KEeL/ridbjWJ2csFJ/t5aIO9cBl78oijsNxhhJ4vLfocDe1gTh1C/IofbfGI70yzfGyDuy/07SJOFitEPBL7El4Rn4qV6lzVF17p1vGQffRbXrJbQX3jL6IqCTPQY= Original-Received: by 10.82.155.10 with SMTP id c10mr7949220bue.1196100674573; Mon, 26 Nov 2007 10:11:14 -0800 (PST) Original-Received: by 10.82.166.1 with HTTP; Mon, 26 Nov 2007 10:11:14 -0800 (PST) In-Reply-To: <2bc5f8210710290737j32fe7b1s86aaa7e084bb69b6@mail.gmail.com> 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:6895 Archived-At: Hi guys, Just wanted to see if anyone had had a chance to take a look at the patch I attached to the last message on this thread. Once again, I know it's big for a patch (I'd be glad to break it into a few smaller patches), but about half of it is Scheme code. I'd be happy to explain / discuss any aspect of it! Regards, Julian On Oct 29, 2007 9:37 AM, Julian Graham wrote: > Hi Guilers, > > Find attached a first draft of a patch to add SRFI-18 support to > Guile. The patch contains the necessary modifications to Guile's C > code to support SRFI-18, which is provided as a Scheme module (also > attached). I don't believe any breaking changes to the API are > introduced by this code, and, in general, the only behavior that is > significantly different is that which was previously "unspecified" or > of dubious correctness -- e.g., unlocking mutexes from outside the > threads that originally locked them, or leaving abandoned mutexes > locked forever. > > I realize this is kind of a big patch, so I've included some, uh, > commentary to help you guys sift through it. I'm working on updating > the Texinfo documentation, but didn't want to wait to submit, as the > scope and content of this patch could conceivably change. I'm also > attaching some test code that might be helpful in illustrating some of > the concepts involved in SRFI-18. Of course, I also encourage everyone > to take a look at the SRFI itself, which is available at > http://srfi.schemers.org/srfi-18/srfi-18.html. > > Please let me know if you have any questions / comments! > > > Best Regards, > Julian > > > SIGNIFICANT CHANGES TO THREADS.H > ================================ > > * Three members have been added to the thread data structure: > > ** admin_mutex, which is a lighter-weight version of the > thread_admin_mutex, which should be used instead of thread_admin_mutex > in situations requiring synchronous access to thread-specific > information, such as checking whether a thread has been marked exited, > that do not require access to the global list of threads > > ** mutexes, a SCM list of mutexes owned by a thread. This is > necessary so that threads waiting on mutexes that an exiting thread is > abandoning can be notified > > ** exception, a SCM holding any uncaught exceptions thrown by the > thread or its cleanup handler. We need this so we can deliver > uncaught exceptions to threads that join on a terminated thread > > > NEW C FUNCTIONS > =============== > > * scm_join_thread_timed (t, timeout, timeout_val): An overload of > scm_join_thread featuring extended timeout semantics from SRFI-18 > * scm_thread_p (obj): A type predicate for threads > * scm_lock_mutex_timed (m, abstime, thread): An overload of > scm_lock_mutex featuring extended timeout and ownership semantics from > SRFI-18 > * scm_unlock_mutex_timed (m, cond, abstime): An overload of > scm_unlock_mutex featuring extended timeout semantics from SRFI-18 > * scm_mutex_state (m): Mutex state reporting from SRFI-18 > * scm_mutex_p (obj): A type predicate for mutexes > * scm_condition_variable_p (obj): A type predicate for condition variables > > > NEW SCHEME FUNCTIONS (without loading SRFI-18) > ============================================== > > * join-thread thread -> join-thread thread [timeout [timeoutval]] > * thread? obj > * lock-mutex mutex -> lock-mutex mutex [timeout [owner]] > * unlock-mutex mutex -> unlock-mutex mutex [cond [timeout]] > * mutex-state mutex > * mutex? obj > * condition-variable? obj > > > SIGNIFICANT CHANGES TO THREADS.C > ================================ > > * A static function, scm_to_timespec, has been added to thread.c that > converts SCM timeouts -- either in numerical form or as (secs . usecs) > -- to an scm_t_timespec > > * Because the owner of a locked mutex can be #f, unblock_from_queue > now returns SCM_UNDEFINED when a queue is empty, in order to avoid > ambiguity. This is purely for consistency -- #f cannot actually be > added to a queue > > * The catch calls in do_thread_exit and really_launch now include a > handler (if the caller does not specify one already), > exception_preserve_catch_handler, which saves exception data in the > thread's exception field > > * scm_join_thread, which now calls scm_join_thread_timed, will rethrow > any uncaught exceptions thrown by the terminated thread > > * fat_mutex_lock and fat_mutex_unlock now add and remove mutexes from > a thread's list of locked mutexes. As part of thread exit, other > threads waiting on mutexes in this list are woken up > > * An unlocked fat_mutex now has its owner set to SCM_UNDEFINED, not SCM_BOOL_F > > * fat_mutex_lock has been largely rewritten (although the behavior is > almost exactly the same for calls that do not specify a timeout) in > order to deal with SRFI-18's concept of mutex states. It is now a loop > that synchronously inspects the current state of the mutex to > determine whether it can be locked, sleeping on the mutex's condition > variable if it cannot be. As per SRFI-18, an attempt to lock an > abandoned mutex will succeed, although an abandoned-mutex-exception > will be thrown. fat_mutex_lock now returns an exception instead of a > char *, indicating the success of the lock via a passed-in int > pointer. > > * fat_mutex_unlock now allows a mutex to be unlocked from any thread, > as per SRFI-18 > > > SIGNIFICANT CHANGES TO SCMSIGS.C > ================================ > > * The scm_spawn_thread call that launches the signal delivery thread > no longer specifies a handler. No one should call scm_spawn_thread > with a handler, because of an already-present deadlock in 1.8.x -- in > a multithreaded context, a guile mode thread (i.e., one that has > locked its heap mutex) may attempt to enter a critical section in > eval.i.c at the same time a non-guile mode thread created by > scm_spawn_thread is within a critical section in make_jmpbuf while > setting up a catch handler and attempts to do a GC > _______________________________________________ Guile-devel mailing list Guile-devel@gnu.org http://lists.gnu.org/mailman/listinfo/guile-devel