Commit [d0511d]  Maximize  Restore  History

Fix/bandaid for some more threading problems (though
regrettably only the easy ones)

... when stopping threads for GC, if kill() fails assume this
is because the thread died after outliving its parent so
nothing was available to set th->state=STATE_DEAD when it
exited. Mark said thread dead, Ted.

(Note: still doesn't cope with pid recycling. In the
unlikely-unless-malefactor-involved case that a pid
previously used for a thread died after its parent and now
belongs to an unrelated process which the current user has
permission to kill it, it will probably die in the next
GC. Exploits on a postcasrd to the usual address, please)

... interrupt_thread() now checks that the thread is one we
know about (instead of just some random other process)
and refuses to kill if it's not. INTERRUPT-THREAD now
catches this and other errors from kill() and signals a
more useful condition than the provious "unexpected system
call failure"

... only the parent of a thread can identify whether it is a
zombie, which it should usually do when it gets a
SIG_THREAD_EXIT. It's possible that this signal may go
missing if delivered during pseudoatomic or similar, so
for the sake of being able to GC we ask each thread to
check its children again in the stop_for_gc_handler before
going to sleep

Thread documentation update based on the LSM lightning talk

Daniel Barlow Daniel Barlow 2004-08-16

changed doc/manual/beyond-ansi.texinfo
changed src/code/debug.lisp
changed src/code/target-thread.lisp
changed src/runtime/interrupt.c
changed src/runtime/thread.c
changed version.lisp-expr
doc/manual/beyond-ansi.texinfo Diff Switch to side-by-side view
src/code/debug.lisp Diff Switch to side-by-side view
src/code/target-thread.lisp Diff Switch to side-by-side view
src/runtime/interrupt.c Diff Switch to side-by-side view
src/runtime/thread.c Diff Switch to side-by-side view
version.lisp-expr Diff Switch to side-by-side view

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:

No, thanks