[Ecls-list] Locking strategy (best so far)
Juan Jose Garcia-Ripoll
juanjose.garciaripoll at googlemail.com
Tue Apr 3 07:51:59 UTC 2012
On Sat, Mar 31, 2012 at 12:13 PM, Matthew Mondor
<mm_lists at pulsar-zone.net>wrote:
> It appears that it locks before all initial threads of the HTTPd can be
> started. The REPL doesn't come back while that thread appears to be
> waiting on a pthread_cond_wait(3) forever without getting an event.
> This happens inside the GC, invoked sometime during HTTPD-INIT (that
> happens in the first/main thread):
> #0 0x00007f7ff6a76eda in ___lwp_park50 () from /usr/lib/libc.so.12
> #1 0x00007f7ff72088f4 in pthread_cond_timedwait (abstime=0x0,
> mutex=0x7f7ff7b010e8, cond=0x7f7ff7b01118) at
> #2 pthread_cond_wait (cond=0x7f7ff7b01118, mutex=0x7f7ff7b010e8) at
> #3 0x00007f7ff7205cc1 in sem_wait (sem=0x7f7ff60408f0) at
> #4 0x00007f7ff5e187d8 in GC_stop_world () from /usr/pkg/lib/libgc.so.1
This is where the garbage collector tries to suspend all threads that were
running and registered with it. It is waiting probably for the ok from
every thread but...
As for the other successfully-started threads (there are 9 of these,
> 8 of which are waiting in sigsuspend(2)) after an attempt to obtain the
> global accept-lock unsuccessfully (as the first thread acquired it).
> #0 0x00007f7ff6a38eca in _sys___sigsuspend14 () from /usr/lib/libc.so.12
> #1 0x00007f7ff7206732 in __sigsuspend14 (sigmask=<optimized out>) at
> #2 0x00007f7ff777f341 in ecl_wait_on (env=0x7f7ff7ed8000,
> condition=0x7f7ff777105a <get_lock_inner>, o=0x28b5f90)
... somehow these threads did not respond to the signal. I do not really
understand it. Was it before a change I did recently? ECL now _only_ blocks
its communication signal in sigsuspend(). It should not be blocking the
signal from the garbage collector.
Instituto de Física Fundamental, CSIC
c/ Serrano, 113b, Madrid 28006 (Spain)
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the ecl-devel