[Ecls-list] Slightly disruptive change (in threads)

[Matthew Mondor]

On Fri, 17 Feb 2012 20:41:00 +0100
Juan Jose Garcia-Ripoll <juanjose.garciaripoll at googlemail.com> wrote:

> On Fri, Feb 17, 2012 at 8:30 PM, Matthew Mondor <mm_lists at pulsar-zone.net>wrote:
> 
> > I'm unfortunately not familiar enough with boehm-gc, but is it possible
> > that it still uses OS-provided mutexes when ECL uses its own locks?  If
> > so, could it cause issues?  Or can ECL feed boehm-gc its own locking
> > primitives which it uses?  Does it matter at all?
> 
> 
> There should be no problem with this. At most the garbage collector might
> try to suspend ECL while locking and that leave the whole system in an
> indeterminate state, but AFAI the spinlock construct I made is robust
> against interrupts.
> 
> Thanks for the other information. I will try to use it during the weekend.
> I also have some idea on how to implement a wakeup system.

I've been thinking a bit about the wakeup problem too but so far only
have had rather ugly ideas such as using a file descriptor a-la-PTH or
a user signal catched which isn't blocked by any thread but which is
specially handled, both of which would add syscall overhead too...

Oh, some details I forgot to mention:

*debug* can specify what to log and if to enable/disable /test
LOG-TAIL will display the backlog if any, up to 1000 lines by default (syslog/file logging not implemented yet)
LOG-CLEAR will clear the log
SERVER-STAT will show a summary of the threads and their states
SERVER-STAT-VERBOSE will show per-thread information

For client-serving threads, there is a custom debugger hook which
simply logs the error with a simple backtrace.  In theory no error
should ever propagate from them to the REPL, so I'm always surprised
when I see a spurious debugger manifestation (rare, but it can occur
when the image becomes unstable).

As for the versions of gmp, boehm-gc, libffi, they are simply the ones
from pkgsrc-2011Q4.

Thanks,
-- 
Matt