The language itself also has some serious race conditions that are impossible to debug unless you're on really slow/embedded hardware. For example, I used the Dillo web browser (which is FLTK-based) for a couple years when I was stuck on an 800MHz PC, and when the system was swapping heavily, doing things like opening the (FLTK-generated) file-save dialog or dragging a window scrollbar (IIRC) would lock the mouse - FLTK uses X11 cursor locks to constrain the cursor in some situations, and due to the system's heavy I/O load, FLTK wasn't releasing the locks, and I had to kill the entire browser.
Hmm. Good point; AFAIK Dillo doesn't use threading.
I'm honestly not sure what was causing it, but I know that it only happened when the system was swapping a lot. So something that expected something else to be done or take a short amount of time didn't.
For all I know it could be the way FLTK is using Xlib (I don't think it uses XCB yet).
