Browse thread
more patches (for Unix signal mask)
-
Joerg Czeranski
- Joerg Czeranski
-
Xavier Leroy
- Joerg Czeranski
- Joerg Czeranski
[
Home
]
[ Index:
by date
|
by threads
]
[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
| Date: | -- (:) |
| From: | Joerg Czeranski <jc@j...> |
| Subject: | Re: more patches (for Unix signal mask) |
Xavier Leroy answered to my mail: > > I replaced all sigsetjmp() calls with _setjmp() calls (setjmp() is > > allowed to modify the signal mask, too, as per Single Unix Spec v2) > > and handled jumps out of signal handlers separately. > > That's an interesting idea; I'll have to think about it. By the way, > you can just do sigsetjmp(..., 0) if you don't want the signal mask to > be saved and restored; this is more portable than _setjmp. Ah, I missed that in the man page, I'll have a look if it has no unexpected side effects ;-) to use sigsetjmp(..., 0). > > Exceptions on the other hand go straight up the stack until they find > > a handler, and then *immediately* invalidate the handler. > > In a non-pure programming language like O'Caml this creates unavoidable > > race conditions: > > let resource = acquire () in > > try > > use resource; > > release resource > > with e -> > > release resource; > > raise e > > "release" is never called if two exceptions arrive at virtually > > the same time, and neither if an exception arrives after the call > > to "acquire", but before the "try". > > Yes, asynchronous exceptions (such as those generated from a signal > handler) are very hard to use because of this. The programming idiom > you showed above is safe for synchronous exceptions (exceptions that > can only be raised by "use resource"), however. What about resource problems like stack overflows and running out of heap memory? I think they might happen at the call to "release". But it probably depends on the interna of the release function. > My take on this is that exceptions as they are implemented now are > just fine as a non-local control structure inside a sequential > program, but that something else is needed for multithreaded and > signal-based processing. The thread cancellation model of Posix threads > is an interesting example of how inter-thread asynchronous > notifications can be made safe. Maybe signals should be handled in a completely different way, not via handlers, but as a special kind of input stream. A function similar to Unix.select (even a wrapper around it) could provide signal notification service. Such a model might be useful for C programs too. I never got around to trying this idea though. Maybe I'll try to write such a function for O'Caml as an alternative to the Sys.signal facility. joerch