Re: console-client signal handling

[Marco Gerards]

Marcus Brinkmann <marcus.brinkmann@ruhr-uni-bochum.de> writes:

> It's also questionable if you really want another thread to wait on a
> condition all the time.  OTOH, there probably is no suitable other
> thread.  So, if we need another thread, then that's ok.  But block
> signals for all other threads, and have that thread also handle the
> signals you want to catch.  That's best because then memory is already
> synchronized.  Having that thread sleep most of the time and check for the

I have tried blocking signals for other threads but I have little luck
so far.  It seems that there is no way to block signals for all new
threads that will be created, or are they blocked when created.  From
what I can tell, they are not.

But my main problem is that when I block signals for the main thread,
other threads don't handle the signal.

In the main function the first thing I do is setting up a signal
handler.  After that I create a new thread that should handle the
signals and check the flag (I will try if I can use pause or sigwait
for that).  After the thread is created, I use the following code
block the relevant signals for this thread:

  struct hurd_sigstate *ss;
  sigset_t mask;
  sigemptyset (&mask);
  sigaddset (&mask, SIGTERM);
  sigaddset (&mask, SIGINT);
  sigaddset (&mask, SIGHUP);
  ss = _hurd_self_sigstate ();
  ss->blocked = mask;

This code works perfectly.  The main thread does not handle the
signals anymore.  But what confuses me is that signals aren't handled
anymore (at all).  This was what I tried to unblock the newly created
thread (which AFAIK is not blocked), this code is run inside that
thread:

  struct hurd_sigstate *ss;
  ss = _hurd_self_sigstate ();
  sigemptyset (&ss->blocked);

This did do what I hoped it would do (although I did not really expect it
would).  I just want to make clear the thread does not block signals.

Can someone please tell me what I did wrong or what would be a better
way to do this?

Thanks,
Marco