That's correct. Unfortunately there is not much, we can do about it. 

A solution would be to always write into the wakeup pipe and try to empty it before the poll, but there'd be still a race condition.

So if you need to wakeup the poll from within a signal handler, open your own pipe for it, add it to the poll, and write into that in the signal handler. Note though that a filled buffer for the pipe might, depending on fcntl options, cause the signal handler and thus the whole program to hang. Another reason to avoid writing into the pipe without knowing, whether someone is listening.

Could we get away without the locking if we change poll_waiting atomically ?

I think, doing it atomically wouldn't help, as we need to test for poll_waiting, write the char and set it all atomically, to make the following asumption in glib/gmain.c work:

   2499   if (!context->poll_waiting)
   2500     {
   2501 #ifndef G_OS_WIN32
   2502       gchar a;
   2503       read (context->wake_up_pipe[0], &a, 1);
   2504 #endif
   2505     }

There certainly is a way to make it work without locks, but getting the logic right would be a real pain and it would surely be less efficient (OK, the latter is not really an issue here, I assume).