From root at common-lisp.net Mon Jul 17 06:01:23 2006 From: root at common-lisp.net (root) Date: Mon, 17 Jul 2006 02:01:23 -0400 (EDT) Subject: [ssc-devel] Auto-nag: ssc please update your webpage Message-ID: <20060717060123.A3675402F@common-lisp.net> You are being nagged on because you have not created a sensible default webpage for your project. Please do so or you will be nagged again next week. All we ask is that you type in something about the project and perhaps some links to mailinglists etc. See common-lisp.net/project/clo/sp/index.html for a reasonable template. Some projects host their webpages somewhere else (eg. http://common-lisp.net/project/cl-ppcre) and if you're in the same situation you may put the following in your index.shtml: Any questions? You can reach the author of this cronjob at clo-devel at common-lisp.net Thanks! From masm at acm.org Fri Jul 28 17:32:01 2006 From: masm at acm.org (Marco Monteiro) Date: Fri, 28 Jul 2006 18:32:01 +0100 Subject: [ssc-devel] WAIT-CONDVAR/TIMEOUT is not implementable. Message-ID: <44CA4A11.2010803@acm.org> The problem is that after the lock is released, we cannot respect the timeout because we must re-acquire the lock before returning. Three possible solutions: * drop the function * change the semantics so that the lock is not re-acquired before the function returns * specify that the re-acquiring of the lock has this problem and the function cannot be used reliably (although it is still useful in most cases.) POSIX threads has the third behaviour. The second is not the right thing(R), but I see uses for it. Comments, please. Cheers, Marco From masm at acm.org Sat Jul 29 17:18:11 2006 From: masm at acm.org (Marco Monteiro) Date: Sat, 29 Jul 2006 18:18:11 +0100 Subject: [ssc-devel] Names of synchronization objects Message-ID: <44CB9853.40903@acm.org> All synchronization objects have names. Names can be used to help debugging: although there is still no way to get information on what a thread is up to (like the PROCESS-WHOSTATE in some implementations) this will probably be added in the future. The name mechanism is currently used by some implementations. I now think that this is not the right way to do it, for at least to reasons: * (minor reason) a thread can be acquiring a lock, or waiting on a condition variable, or passing a barrier, etc., in several different places. With the name, this cannot be discerned: a thread can be deadlocked in one of many different places. * (major reason) imagine you build some abstractions over SSC, like monitors, bounded-buffer, etc. These will be implemented with locks and condition variables, etc. If a thread is blocked because a bounded buffer is full, the 'whostate' of the process will be something like "Blocked on lock 'buffers's lock'", instead of something more reasonable like "Adding client to buffer". So, what if we drop names from all synchronization objects and instead add a &key argument to all function that can block? Basically, I'm proposing taking the approach of PROCESS-WAIT of some implementations, that accepts a whostate argument, and extend it to all functions that can block. We would then have code user like: (with-lock (mutex :info "Mutual exclusion to list of clients") (loop while (list-full-p list) do (condvar-wait cv :info "List of clients is full")) ...) and code built on a bounded-buffer implemented on SSC: (put process-bbuffer client :info "Add client for process buffer") Please comment. Cheers, Marco