Re: [Sbcl-devel] fd-streams threading patch

[Daniel B. <da...@te...>]

Brian Downing <bdo...@la...> writes:

> It seems that if a thread is destroyed, the process dead, but a GC happens
> before the lock in destroy_thread, you will have countdown_to_gc never go=
ing to
> zero.=20

On closer inspection, maybe I was right after all.

If a thread is destroyed, but a GC happens before the lock in
destroy_thread, gc_stop_the_world will loop (using sched_yield, so in
as nice a way as it _can_ loop) polling countdown_to_gc until the
parent process (which is not a Lisp thread at all, and is not stopped
by gc_stop_the_world) returns from wait() and calls destroy_thread.
destroy_thread decrements countdown_to_gc if it's non-zero, allowing
gc_stop_the_world to terminate and garbage collectionn to happen.

Or am I still missing something?

This is not _exactly_ the right thing to do: the thread might have
been between countdown_to_gc-- and kill(self, SIGSTOP) when it was
killed.  But all normal signals are masked at that point, so you'd
have to be using kill -9, so probably you should expect to lose there.
Not least because it will leave all_threads_lock locked, so nothing=20
interesting can ever happen again.

> Perhaps countdown_to_gc should only be incremented if the signal is
> successfully delivered.

Unfortunately, killing a zombie returns 0 (success), so we couldn't
have done it that way anyway.


=2Ddan

=2D-=20

   http://www.cliki.net/ - Link farm for free CL-on-Unix resources=20