For MacOS pthreads, sigwait() Does Not Handle a Signal - macos

When running the following, the sigwait() never handles the SIGUSR1 signal. Basic setup is: main spawns two pthreads: one a handler thread and one a worker thread. The main thread and both spawned threads block SIGUSR1. The worker raises SIGUSR1 twice with a two second delay. The handler thread never sees it.
This is on MacOS. When running from Xcode I insert a continuable breakpoint that executes pro hand -p true -s false SIGUSR1. If I run the executable from the command line, the same output occurs.
Why does sigwait() not see the raised SIGUSR1?
Here is the output:
SigHandlerThread: Waiting: 30
Raise
Raise
Program ended with exit code: 0
Here is the code:
//
// Signal Test
//
typedef void* (*ThreadRoutine) (void*); // pthread_create
void workerRaise (int signum) {
sleep (2);
printf ("Raise\n");
raise (signum);
}
void sigBlock (sigset_t *set, int signum) {
sigemptyset(set);
sigaddset(set, signum);
pthread_sigmask(SIG_BLOCK, set, NULL);
}
void *sigHandlerThread (void *ignore) {
int signal;
sigset_t blockSignalSet;
sigBlock(&blockSignalSet, SIGUSR1);
printf ("SigHandlerThread: Waiting: %d\n", SIGUSR1);
while (0 == sigwait(&blockSignalSet, &signal))
printf ("SigHandlerThread: %d\n", signal);
printf ("SigHandlerThread: Exit (0 != sigwait())\n");
return NULL;
}
void *workerThread (void *ignore) {
sigset_t blockSignalSet;
sigBlock(&blockSignalSet, SIGUSR1);
workerRaise(SIGUSR1);
workerRaise(SIGUSR1);
pthread_exit(NULL);
}
// Called from main.
void testSignal () {
sigset_t blockSignalSet;
sigBlock(&blockSignalSet, SIGUSR1);
pthread_t worker, handler;
pthread_create (&handler, NULL, (ThreadRoutine) sigHandlerThread, NULL);
pthread_create (&worker, NULL, (ThreadRoutine) workerThread, NULL);
pthread_join(worker, NULL);
sleep (2);
}

The raise() function sends the signal directed specifically at the calling thread - other threads in the process won't receive it. raise(signum) is equivalent to pthread_kill(pthread_self(), signum).
What you need is a process-directed signal, not a thread-directed signal. Instead of using raise(signum), use kill(getpid(), signum).

Related

How to CancelSynchronousIo() on WaitForSingleObject() waiting on stdin?

On Windows 10, I'm waiting for input from the console using
WaitForSingleObject( GetStdHandle(STD_INPUT_HANDLE), ... )
and to cancel this waiting using CancelSynchronousIo().
But the cancellation does nothing (returns 0 and GetLastError() is ERROR_NOT_FOUND).
Any idea what I could be doing wrong?
Should I be able to cancel this waiting for new input on stdin?
(I actually want to do this with any HANDLE whose GetFileType() is FILE_TYPE_CHAR, not only stdin, but stdin is certainly the most important use case and the simplest to test with).
Related discussions I've found:
Synchronous ReadFile() on stdin cannot be unblocked by CancelSynchronousIo()
win32: how stop ReadFile (stdin|pipe)
But unfortunately they only discuss ReadFile(), not WaitForSingleObject(). I've also tried WaitForMultipleObjects() (with just a single object in the array), same problem.
(Background: I'm trying to improve input handling in the GHC Haskell compiler runtime.)
CancelSynchronousIo cancel I/O operations that are issued by the specified thread. more concrete it cancel IRP packets which associated with specified thread via call IoCancelIrp. if use undocumented NtCancelSynchronousIoFile (CancelSynchronousIo internally call it with IoRequestToCancel = 0) we can be more selective - cancel only i/o request which used specified IoRequestToCancel (system check that Irp->UserIosb == IoRequestToCancel and cancel only this requests)
but WaitForSingleObject this is not I/O request. this call not create any IRP which can be canceled. so - no way do this.
however if you use WaitForSingleObjectEx with bAlertable set to TRUE - you can break wait by queue apc to thread by using QueueUserAPC . also if use NtWaitForSingleObject instead WaitForSingleObjectEx we can also alert thread by using undocumented call NtAlertThread. in this case NtWaitForSingleObject will break with STATUS_ALERTED (note that WaitForSingleObjectEx which internally call NtWaitForSingleObject do special check for STATUS_ALERTED and in case this status - again run NtWaitForSingleObject - as result we can not break WaitForSingleObjectEx by call NtAlertThread, but NtWaitForSingleObject will be breaked.
so if you need break waiting for std input - create additional thread, which must call not CancelSynchronousIo (this senseless) but QueueUserAPC or NtAlertThread (only if you use NtWaitForSingleObject for wait). and input thread must wait in alertable state. so demo code can look like:
extern "C" NTSYSCALLAPI NTSTATUS NTAPI NtAlertThread(HANDLE ThreadHandle);
VOID NTAPI OnApc(ULONG_PTR Parameter)
{
DbgPrint("OnApc(%p)\n", Parameter);
}
DWORD CALLBACK BreakWaitThread(HANDLE hThread)
{
switch (LONG status = MessageBoxW(0, L"Use Apc(yes) or Alert(No) ?", L"BreakWaitThread",
MB_ICONQUESTION|MB_YESNOCANCEL|MB_DEFBUTTON3))
{
case IDYES:
if (!QueueUserAPC(OnApc, hThread, 0))
{
DbgPrint("QueueUserAPC=%u\n", GetLastError());
}
break;
case IDNO:
if (0 > (status = NtAlertThread(hThread)))
{
DbgPrint("AlertThread=%x\n", status);
}
break;
case IDCANCEL:
DbgPrint("canceled\n");
break;
default:
DbgPrint("MessageBox=%x\n", status);
}
CloseHandle(hThread);
return 0;
}
void ConsoleLoop(HANDLE hStdIn)
{
ULONG NumberOfEvents, NumberOfEventsRead, n;
INPUT_RECORD buf[8], *p;
for (;;)
{
switch (ZwWaitForSingleObject(hStdIn, TRUE, 0))
//switch (WaitForSingleObjectEx(hStdIn, INFINITE, TRUE))
{
case WAIT_OBJECT_0:
while (GetNumberOfConsoleInputEvents(hStdIn, &NumberOfEvents) && NumberOfEvents)
{
do
{
NumberOfEventsRead = min(RTL_NUMBER_OF(buf), NumberOfEvents);
if (ReadConsoleInput(hStdIn, buf, NumberOfEventsRead, &NumberOfEventsRead) && NumberOfEventsRead)
{
n = NumberOfEventsRead;
p = buf;
do
{
if (p->EventType == KEY_EVENT)
{
DbgPrint("%u(%u) %C %x %x %x\n",
p->Event.KeyEvent.bKeyDown,
p->Event.KeyEvent.wRepeatCount,
p->Event.KeyEvent.uChar.UnicodeChar,
p->Event.KeyEvent.wVirtualKeyCode,
p->Event.KeyEvent.wVirtualScanCode,
p->Event.KeyEvent.dwControlKeyState);
if (VK_OEM_PERIOD == p->Event.KeyEvent.wVirtualKeyCode)
{
return ;//if user type '.' return for demo
}
}
} while (p++, --n);
}
else
{
FlushConsoleInputBuffer(hStdIn);
break;
}
} while (NumberOfEvents -= NumberOfEventsRead);
}
continue;
case STATUS_USER_APC:
DbgPrint("\nUSER_APC\n");
return;
case STATUS_ALERTED:
DbgPrint("\nALERTED\n");
return;
case WAIT_FAILED :
DbgPrint("\nWAIT_FAILED=%u\n", GetLastError());
return;
default:
__debugbreak();
return;
}
}
}
void SimpleDemo()
{
if (HANDLE hCurrentThread = OpenThread(THREAD_ALERT|THREAD_SET_CONTEXT , FALSE, GetCurrentThreadId()))
{
ULONG dwThreadId;
HANDLE hThread = CreateThread(0, 0, BreakWaitThread, hCurrentThread, 0, &dwThreadId);
if (hThread)
{
ConsoleLoop(GetStdHandle(STD_INPUT_HANDLE));
PostThreadMessage(dwThreadId, WM_QUIT, 0, 0);
WaitForSingleObject(hThread, INFINITE);
CloseHandle(hThread);
}
else
{
CloseHandle(hCurrentThread);
}
}
}
Console I/O is difficult to use asynchronously, it is simply not designed for it. See IO Completion Ports (IOCP) and Asynchronous I/O through STDIN, STDOUT and STDERR for some possible workarounds.
If that is not an option for you, then you will have to either:
use WaitForSingleObject() in a loop with a short timeout. Create a flag variable that your loop can look at on each iteration to break the loop if the flag is set.
use WaitForMutipleObjects(), giving it 2 HANDLEs to wait on - one for the console (or whatever), and one for an event object from CreateEvent(). Then you can signal the event with SetEvent() when you want to break the wait. The return value of WaitForMutipleObjects() will tell you which HANDLE was signaled.

QueueUserAPC fails with invalid handle?

I'm trying to figure out why QueueUserAPC fails, the error code is 6, which is ERROR_INVALID_HANDLE
The DLL exists, the OpenThread works too,
Attached source code,
int _tmain(int argc, _TCHAR* argv[])
{
DWORD pid;
vector<DWORD> tids;
if (FindProcess(L"calc.exe", pid, tids)) {
HANDLE hProcess = ::OpenProcess(PROCESS_VM_WRITE | PROCESS_VM_OPERATION, FALSE, pid);
auto p = ::VirtualAllocEx(hProcess, nullptr, 1 << 12, MEM_COMMIT | MEM_RESERVE, PAGE_READWRITE);
wchar_t buffer[] = L"c:\\msgbox.dll";
::WriteProcessMemory(hProcess, p, buffer, sizeof(buffer), nullptr);
for (const auto& tid : tids) {
HANDLE hThread = ::OpenThread(THREAD_SET_CONTEXT, FALSE, tid);
if (hThread != INVALID_HANDLE_VALUE) {
::QueueUserAPC((PAPCFUNC)::GetProcAddress(GetModuleHandle(L"kernel32"), "LoadLibraryW"), hThread, (ULONG_PTR)p);
printf ("QueueUserAPC: %d\n", GetLastError());
} else {
printf ("OpenThread failed (%d): %d\n", tid, GetLastError());
}
}
::VirtualFreeEx(hProcess, p, 0, MEM_RELEASE | MEM_DECOMMIT);
} else {
puts ("process not found");
}
return 0;
}
OpenThread -
If the function fails, the return value is NULL.
so condition
if (hThread != INVALID_HANDLE_VALUE)
is error. need
if (hThread != NULL)// or if (hThread)
I guess that in your case hThread == 0
also need understand that:
When a user-mode APC is queued, the thread is not directed to call the
APC function unless it is in an alertable state.
really even if you use correct thread id/handle - your code will be no effect - APC not executed. insert APC have sense only if you know what thread is doing, that he wait for APC.
one is point, when QueueUserAPC worked - if you yourself call CreateProcess with CREATE_SUSPENDED and then call QueueUserAPC (in xp before call QueueUserAPC you must call GetThreadContext because xp at thread start insert also internal insert APC to it (to LdrInitializeThunk) - and if you just (without arbitrary wait or GetThreadContext(this is exactly wait) call QueueUserAPC - your APC can inserted before system APC - as result process begin executed not from LdrInitializeThunk but from your func and crashed. begin from vista this problem is gone and we can not use this hack) .
this will be worked because just before call exe entry point ntdll always call ZwTestAlert - this call check - are exist APC in thread queue and execute it. as result your APC will execute after all DLL in process got DLL_PROCESS_ATTACH, TLS initialized, etc.. but just before exe entry point begin executed. in context of first thread in process. for this case use QueueUserAPC the best injection way

understanding ZMQ - PAIR Sockets for multi-threading

Refer to http://hintjens.wdfiles.com/local--files/main:files/cc1pe.pdf
page 67.
Question> I don't see why the following code is good for multi-thread. Based on my understanding, the main thread can do different things while waiting for the feedback from child thread.
However, in the following code, it seems that the step2 is blocked while calling char *string = s_recv (receiver); and step3 is blocked while calling char *string = s_recv (receiver);
Based on my understanding, (step_i+1) is able to do something free until the signal is received from step_i. however, as you can see the code, both the step2 and step3 are blocked and cannot do anything. Why this is a multi-thread code?
Thank you
// Multithreaded relay
#include "zhelpers.h"
#include <pthread.h>
static void *
step1 (void *context) {
// Connect to step2 and tell it we're ready
void *xmitter = zmq_socket (context, ZMQ_PAIR);
zmq_connect (xmitter, "inproc://step2");
printf ("Step 1 ready, signaling step 2\n");
s_send (xmitter, "READY");
zmq_close (xmitter);
return NULL;
}
static void *
step2 (void *context) {
// Bind inproc socket before starting step1
void *receiver = zmq_socket (context, ZMQ_PAIR);
zmq_bind (receiver, "inproc://step2");
pthread_t thread;
pthread_create (&thread, NULL, step1, context);
// Wait for signal and pass it on
char *string = s_recv (receiver);
free (string);
zmq_close (receiver);
// Connect to step3 and tell it we're ready
void *xmitter = zmq_socket (context, ZMQ_PAIR);
zmq_connect (xmitter, "inproc://step3");
printf ("Step 2 ready, signaling step 3\n");
s_send (xmitter, "READY");
zmq_close (xmitter);
return NULL;
}
int main (void)
{
void *context = zmq_ctx_new ();
// Bind inproc socket before starting step2
void *receiver = zmq_socket (context, ZMQ_PAIR);
zmq_bind (receiver, "inproc://step3");
pthread_t thread;
pthread_create (&thread, NULL, step2, context);
// Wait for signal
char *string = s_recv (receiver);
free (string);
zmq_close (receiver);
printf ("Test successful!\n");
zmq_ctx_destroy (context);
return 0;
}
The way I read it, the sample code shows only how to let the main thread (step3) know that the other two threads have been created and connected properly. The signal from step1 passes through step2 to step3 so once it arrives there all is set up and ready to go. This ought to happen quite quickly.
When the threads are done, instead of joining them, you could pass a new message around that says DONE. Step 1 sends this message once it's done. Each other step starts waiting for this message once it's done and when it receives one, passes it on to the next step. When step3 receives the DONE message, all threads are done.
Or you could use such message for accumulating the results of each thread's work.
Instead of waiting on an object, you start a synchronous receive of a message. Instead of notifying, you send a message.
So if I understand it right, the multithreaded work is supposed to happen in between these synchronisation messages.
EDIT
it seems that the step2 is blocked while calling s_recv
This is fine in this example, cause step2 has nothing useful to do other than waiting for the READY message. If in your use case a thread has to do work AND regularly check if it has a message waiting for it, it can call zmq_recv in non-blocking mode with the ZMQ_DONTWAIT flag, to check if the message has arrived yet.

Child process won't suicide if parent dies

I have a subprocess (running on MacOS) that I want to kill itself if the parent quits, exits, terminates, is killed or crashes. Having followed the advice from How to make child process die after parent exits? I can't get it to quietly kill itself if the parent program crashes. It will go to 100% CPU until I manually kill it.
Here are the key points of the code:
int main(int argc, char *argv[])
{
// Catch signals
signal(SIGINT, interruptHandler);
signal(SIGABRT, interruptHandler);
signal(SIGTERM, interruptHandler);
signal(SIGPIPE, interruptHandler);
// Create kqueue event filter
int kqueue_fd = kqueue();
struct kevent kev, recv_kev;
EV_SET(&kev, parent_pid, EVFILT_PROC, EV_ADD|EV_ENABLE, NOTE_EXIT, 0, NULL);
kevent(kqueue_fd, &kev, 1, NULL, 0, NULL);
struct pollfd kqpoll;
kqpoll.fd = kqueue_fd;
kqpoll.events = POLLIN;
// Start a run loop
while(processEvents())
{
if(kill(parent_pid, 0) == -1)
if(errno == ESRCH)
break;
if(poll(&kqpoll, 1, 0) == 1)
if(kevent(kqueue_fd, NULL, 0, &recv_kev, 1, NULL))
break;
parent_pid = getppid();
if(parent_pid == 1)
break;
sleep(a_short_time);
// (simple code here causes subprocess to sleep longer if it hasn't
// received any events recently)
}
}
Answering my own question here:
The reason for this problem was not down to detecting whether the parent process had died. In processEvents() I was polling the pipe from the parent process to see if there was any communication. When the parent died, poll() returned a value of 1 and the read loop thought there was infinite data waiting to be read.
The solution was to detect whether the pipe had been disconnected or not.

Multithreaded Win32 GUI message loop

When do you need to use this type of modified message loop in multithreaded application?
DWORD nWaitCount;
HANDLE hWaitArray[4];
BOOL quit;
int exitCode;
while (!quit)
{
MSG msg;
int rc;
rc = MsgWaitForMultipleObjects(nWaitCount, hWaitArray, FALSE, INFINITE,QS_ALLINPUT);
if (rc == WAIT_OBJECT_O + nWaitCount)
{
while (PeekMessage(&msg, NULL, 0, 0, PM_REMOVE))
{
if (msg.message == WM_QUIT)
{
quit = TRUE;
exitCode = msg.wParam;
break;
}
TranslateMessage(&msg);
DispatchMessage(&msg);
}
}
else if (rc >= WAIT_OBJECT_0 && rc < WAIT_OBJECT_0 + nwaitCount)
{
int nlndex = rc - WAIT_OBJECT_0;
}
else if (rc >= WAIT_ABANDONED_0 && rc < WAIT_ABANDONED_0+ nWaitCount)
{
int nlndex = rc - WAIT_ABANDONED_O;
}
}
Hopefully never. But it is the kind of code you have to write when you want the UI thread to block on synchronization objects. A UI thread is not permitted to block, Windows prevents you from calling WaitForMultipleObjects(). The reason is that it is very likely to cause deadlock.
The reason for that is COM. COM is everywhere in Windows, the most common examples are the clipboard, drag+drop and the shell dialogs. COM marshals interface method calls made from a worker thread for COM objects that live on the STA (Single Threaded Apartment) by using the message loop. If the STA thread isn't pumping messages then the call won't complete. And calls that can't complete are ingredient number one for deadlock. Add a UI thread that waits for the worker thread to complete and deadlock is assured.
You avoid this kind of code by having a worker thread use PostMessage() to signal the UI thread that something important happened.

Resources