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 _______________________________________________ Chicken-users mailing list [email protected] https://lists.nongnu.org/mailman/listinfo/chicken-users
