ssc-devel July 2006

ssc-devel@common-lisp.net

2 participants
3 discussions

[ssc-devel] Names of synchronization objects
by Marco Monteiro 29 Jul '06

29 Jul '06

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

1 0

[ssc-devel] WAIT-CONDVAR/TIMEOUT is not implementable.
by Marco Monteiro 28 Jul '06

28 Jul '06

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

1 0

[ssc-devel] Auto-nag: ssc please update your webpage
by root＠common-lisp.net 17 Jul '06

17 Jul '06

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: <HTML> <HEAD> <META HTTP-EQUIV="refresh" CONTENT="0;URL=YOURURLGOESHERE"> </HEAD> <BODY> </BODY> </HTML> Any questions? You can reach the author of this cronjob at clo-devel(a)common-lisp.net Thanks!

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

ssc-devel July 2006