Påhl Melin wrote:
Why can't Unix be a "modern" OS with dynamically allocated
and named signals? :-)
Because if you want that kind of flexibility, you're expected to
provide it yourself, using your knowledge of what will be the best
and most scalable use of available computer resources.
T
> Why can't Unix be a "modern" OS with dynamically allocated
> and named signals? :-)
Signal-handling behavior is so restricted to begin with that more
signals would just end up with more code making non-async-signal-safe
calls. Pipes are easy to create, and can easily be passed from process
to pr
2009/3/25 Benjamin Stiglitz :
>> I'm not completely satisfied using signals (especially since they are
>> not dynamically allocated and I may want to use more in the future)
>> but signals was the lowest level alternative I could think about. This
>> code will be used _very_ frequently and I want t
I'm not completely satisfied using signals (especially since they are
not dynamically allocated and I may want to use more in the future)
but signals was the lowest level alternative I could think about. This
code will be used _very_ frequently and I want to use the lowest
possible level, mainly f
2009/3/25 Ken Thomases :
> Ignoring a signal doesn't prevent it from being delivered. GDB is stopping
> at the point of delivery, _before_ any decision has been made about how to
> handle the signal. The fact that the process will ignore the signal is
> something that is _about to happen_ in the
On Mar 25, 2009, at 5:20 AM, Påhl Melin wrote:
2009/3/25 Ken Thomases :
On Mar 25, 2009, at 2:50 AM, Påhl Melin wrote:
When the singleton is constructed the first time I use
signal(SIGUSR2,
SIG_IGN) to ignore the default signal handler to kill the process.
And
this works great when runnin
2009/3/25 Ken Thomases :
> On Mar 25, 2009, at 2:50 AM, Påhl Melin wrote:
>
>> I have a C++ singleton class where you call methods to execute
>> commands that are actually performed by a background thread. When a
>> command is "requested" it is put in a queue and I use raise(SIGUSR2)
>> to wake-up
On Mar 25, 2009, at 2:50 AM, Påhl Melin wrote:
I have a C++ singleton class where you call methods to execute
commands that are actually performed by a background thread. When a
command is "requested" it is put in a queue and I use raise(SIGUSR2)
to wake-up the background thread. The reason I us
I have a C++ singleton class where you call methods to execute
commands that are actually performed by a background thread. When a
command is "requested" it is put in a queue and I use raise(SIGUSR2)
to wake-up the background thread. The reason I use signals to wake-up
the background thread is that
