Re: [Chicken-users] thread-wait-for-i/o! and thread-terminate!

[Chris Vine]

Jörg F. Wittenberger wrote:
> John is right about the general case.  There are however circumstances
> when you just want to abort some operation.  If you know what you do,
> external abort is sometimes ok.  Most of the time however I'd
> recommend to use thread-signal! to allow the terminated thread
> receive an exception and abort cleanly.
>
> Chicken _itself_ however should not end up in an inconsistent state
> because of thread-terminate!.

As I wrote in my original posting, I know of the dangers, and my _own_
code is termination safe.  The i/o thread which waits on
thread-wait-for-i/o! has a termination mutex, which must always be
acquired by another thread before it calls thread-terminate! on the i/o
thread.  The i/o thread always holds that mutex (to block all
termination events) except when in thread-wait-for-i/o!, which it loops
on, handling i/o events asynchronously as they arrive.  So
thread-terminate! can only be called on it when it is in the
thread-wait-for-i/o! procedure.

So my question was, as you say, whether chicken _itself_ could end up
in an inconsistent state because of thread-terminate!

The other option which I had in mind (if chicken _itself_ is termination
unsafe) was to cause thread-wait-for-i/o! to unblock by closing the
file descriptor.  However, the program logic works better if the
descriptor is not closed (it might be needed again).  Using
thread-signal! had not occurred to me, partly because it is not in
SRFI-18 and partly because the chicken documentation seems impenetrable
on what it does: "This will cause THREAD to signal the condition X once
it is scheduled for execution. After signalling the condition, the
thread continues with its normal execution."  It looks from what you
say as if it causes a resumable exception in the receiver thread which
can be caught by it with with-exception-handler, which would work OK for
my purposes. (I thought SRFI-18 exceptions were non-continuable?).

However, if chicken itself is termination safe then I think that I can
stick with my current approach.

Chris