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