In my case, GUI processing is in the main thread in each of the processes (parent and forked child), which keeps things happy for normal FLTK run time processing. Messages are handled separately by a secondary (listener) thread on each side. Interprocess communication (IPC) is via the Unix pipe(2) 2-way link (read & write file descriptor pairs) between the processes. Outgoing messages are typically originated from within FLTK callbacks in a non-blocking way. Incoming messages are enqueued by the listener thread on the other end. These messages are interpreted in the main loop on that end via an FLTK idle handler. I take care on both ends to make sure things don't block in ways that might result in a deadlock (livelock). The message queuing and asynchronicty between the processes might slow things down, but in practice, it is fast enough for my purposes, at least on Linux (my only platform).

Actually, in the specific case of my animated "wait window widget", the child process does all the animation graphics, and I modify the above scheme so the launcher (parent process) by default does not have a separate listener thread, but itself blocks waiting for the child to emit "finished" (e.g., which happens when Cancel button is pressed, processing reaches completion, the process dies unexpectedly, etc.).