Re: [boost] portable C++ signal handlers?

From: Ryan Gallagher (ryan.gallagher_at_[hidden])
Date: 2006-05-09 21:34:10

Carlo Wood <carlo <at> alinoe.com> writes:
> My ramblings on signals are on http://libcw.sourceforge.net/kernel/signals.html
> Did you read the first paragraph of that (2.1)?

This does look vaguely familiar.  I might have ran into this in my earlier 
(brief) online research.  It's very interesting; I'll review it in more depth
soon.  

> What I try to say there is that you can't expect to DO anything when a
> signal occurs. At most you can increment an atomic counter, and that's it.

Yes this seems to basically agree with dinkumware.  I don't think that this
point had sunk in well enough earlier.  

When I worked on this, I was mainly just worried about closing a bug report 
on one platform.  However, I always prefer something that works just as well 
for more platforms though.  I just hadn't found anything.

Googling "C++ signals" came up with many solutions (some of which are 
inspiration for mine) that do much more than this simple increment.  Many 
throw exceptions or do similar operations to mine with call-backs.  
While not portable to all platforms, I wonder to what platforms
these types of operations can or can't be performed upon.  I guess the question
is "how portable are they?".

> So, if you want an interface that allows call-backs (which I assume
> &database_test_monitor::handle_interruption_and_exit is), then that
> needs to be called later, when the application returns to the main loop.

Good point.  I'll definitely be looking closer at libcw.

The call-back scheme was based upon the idea that it was up to the user
to make sure those call-backs didn't do anything that their system couldn't
handle.  (I have to admit though that writing to a remote database as my 
example handler has done does seem to be a little much.)  My goal for the
signal_registry class itself was to violate as few portability requirements as 
possible (and minor ones at that).  Another goal was to have the least amount 
to change (my application did not have a main loop and the database handle 
was not global).

Anyhow, thanks for the reply and the link.  It seems though that boost
is standard compliance + workarounds for portability so having a library that's
based upon the answer to "how portable are they?" doesn't make sense for it. 
Cheers,

-Ryan