[Ecls-list] Slightly disruptive change (in threads)
mm_lists at pulsar-zone.net
Fri Feb 17 20:07:28 UTC 2012
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
More information about the ecl-devel