On Jan 19 11:38, Corinna Vinschen wrote: > On Jan 19 08:29, SCOTT Damien wrote: > > I have a multi-threaded process running under Cygwin that receives > > messages from several IPC message queues (built using Cygwin's gcc, > > version 4.8.3). The listener for each queue runs in its own thread, > > each of which is created from the main thread. Each listener is using > > a blocking call to msgrcv(). I want the main thread to be able to use > > pthread_kill() to send a SIGUSR1 signal to each listening thread to > > cause it to abandon its call to msgrcv() and then exit. > > > > My approach has been to create a signal mask containing just SIGUSR1 > > and associate this with a signal handler (although the signal handler > > contains no functionality, since all I need is for the blocking call > > to msgrcv() to be abandoned). I initially set the signal mask to > > block in the main thread, which should then be inherited by each of > > the created listening threads. I only unblock the signal mask around > > the call to msgrcv() in each listening thread. > > > > I have included a simplified version of my code below. I usually > > don't see any evidence of the SIGUSR1 signal being received by either > > of the listener threads. Occasionally the first thread unblocks as > > expected but I have never seen both threads unblock. If I change my > > code so that there is only a single listener thread, then everything > > works correctly every time. Changing the msgrcv() call to a sleep > > call also allows unblocking to occur correctly. Note that this > > simplified code does not include removal of the created queues (since > > it never manages to exit anyway) so I manually remove these after each > > run using the ipcrm command. > > > > Example output: > > > > Running thread 2 with queue Id = 1441792 > > Running thread 1 with queue Id = 1179649 > > About to kill thread 1 > > > > Is there an issue with the Cygwin implementation of signal handling, > > or is there a problem with my code? Any help would be much > > appreciated. > > It's an issue with the Cygwin code, probably. The msgrcv code ultimately > hangs in a blocking ReadFile call on a named pipe, and this call is > non-interruptible. Changing that requires a bigger change in Cygwin > which will take time.
...or not. I'm not sure I can fix that for the upcoming 1.7.34 release, but it seems cygserver is using the wrong signal handle. At one point the signal handling got changed a lot to improve per-thread signalling, and, as far as I can see, the cygserver code still assumes a global per-process signal handle, which is the old version from before the change. Just to let you know I'm looking into that. Stay tuned. Oh, btw., there's a bug in your testcase: int id = msgget(key, IPC_CREAT|IPC_EXCL); This call is missing the permission bits, so the permissions are set to 000. The permission bits should be added: int id = msgget(key, IPC_CREAT|IPC_EXCL|S_IWUSR|S_IRUSR); Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat
pgpXx_y1Iride.pgp
Description: PGP signature
