Re: [Chicken-users] Segfault - a hard one

[Thomas Chust]

Jörg F. Wittenberger wrote:

> [...]
> Am Freitag, den 08.08.2008, 00:12 -0700 schrieb Vincent Manis:
> > On 2008-Aug-7, at 19:53, John Cowan wrote:
> > > 1) Run it in a separate process, which you can kill without damaging  
> > > yourself.
> [...]
> But isn't just that run-and-kill (including cleanup) what
> thread-terminate! is supposed to to - just internal to the thread
> system.
> [...]
> So if a separate process and asynchronous kill is a valid alternative, I
> would say thread-terminate! is equivalent.  It might just be cheaper.

Hello,

the striking difference between threads and processes is that processes 
don't share data structures. Thus, when you kill a process, the 
operating system can simply clean up all resources that belonged to it 
and everything is fine. When you kill a thread, you cannot dispose of 
data structures that may be accessed by other threads but you cannot, 
except for some special cases, ensure that the data structures are still 
valid, either. You also break the correct semantics of control 
constructs like dynamic-wind, so all kinds of garbage or illegal state 
may remain in the program's memory, even if the thread that was killed 
was carefully crafted to clean up after itself, simply because the 
cleanup actions will never run.

Therefore, in a thread that might potentially be terminated, you cannot 
safely access any resources that require cleanup not performed by the 
garbage collector, destructively modify any global data structures or 
set any global variables. With processes, these problems don't exist.

> > > 2) Use a modified version of "eval" to execute it that counts ticks.
>
> Valid, but I'm unsure that I can do that.
> [...]

If your thread runs in a loop anyway, shouldn't it be possible to check 
a termination request flag every time a new iteration is about to commence?

> If this modified "eval" needs to interact with compiled code we are
> exactly back where we are: tell the tread system to change the
> continuation of the victim thread to something to inform it about
> asynchronous reasons.
> [...]

If I understand its behaviour correctly, that is not what 
thread-terminate! does. thread-terminate! just stops the thread if it's 
running and removes it from the scheduling system. Changing the current 
continuation of the thread or injecting an exception condition into the 
thread would mean the thread would have a chance to run at least 
dynamic-wind exit hooks, but using thread-terminate! prevents the thread 
from executing any further instructions.

cu,
Thomas