STR #675: All functions in fl_ask.H is not thread safe (using fltk thread model)

STR #675

Application:	FLTK Library
Status:	4 - Pending
Priority:	2 - Low, e.g. a documentation error or undocumented side-effect
Scope:	3 - Applies to all machines and operating systems
Subsystem:	Core Library
Summary:	All functions in fl_ask.H is not thread safe (using fltk thread model)
Version:	2.0-current
Created By:	rus.soyuzkt.od
Assigned To:	matt
Fix Version:	Unassigned
Update Notification:	Receive EMails Don't Receive EMails

Trouble Report Files:

Post File

Trouble Report Comments:

Post Text

#1	rus.soyuzkt.od 03:49 Dec 28, 2004

Calling them correctly (using Fl::lock/Fl::unlock) from different threads makes library segfault. May be some mutex (fl_ask_mutex for ex.) is needed for these functions or, if such things have to be solved at the app level (not the library) than docs have to mention such behavour. TIA

#2	mike 05:52 Dec 28, 2004

I'm not sure there is anything we can do - most systems don't allow multiple threads to create windows, etc. - that has to happen from a single thread (typically the main thread to be compatible with Windows) What OS + compiler are you using?

#3	rus.soyuzkt.od 06:58 Dec 28, 2004

I'm using latest Linux with gcc-3.4.3. Well, may be shoud be some remark in docs, saying that fl_ask* funcs can be called only from main()/Linux or main thread/Windows. TIA

#4	spitzak 00:46 Jan 06, 2005

Unfortunately all "wait" calls do not work from parallel threads. Any plausable implementation is going to have to get the main thread to wake up and do the ask() and then signal the other thread that it is done. Still it would be nice to implement this somehow.

#5	rus.soyuzkt.od 01:14 Jan 06, 2005

It is no need to call wait from different threads. In the correctly designed multithread app the only one thread is calling Fl::wait. The problem that some funcs (fl_ask* for ex) call Fl::wait internally, breaking such apps if the fl_ask* funcs are called from another thread than main. The simple solution is not to call Fl::wait in fl_ask* but only prepare message window, call show() and return. All the work may be done in the Fl::wait().

#6	ramsdell 06:31 Jan 30, 2005

I ran into this problem with Csound, an open source music system that uses FLTK in two ways. You can create a GUI that uses a separate thread to run Csound, and some of music scores processed by Csound create FLTK windows that allow one to modify the sound in real time. I've been modifying Csound so that it is thread safe, and changed the code so that when it creates windows produced by a score, it does not call Fl::wait, but only does a show. On Linux, all is fine, but on Windows, the new windows do not appear. I found the solution on Windows was to show the new windows in a freshly created thread after calling Fl::lock, and then calling Fl::run. This performs the event processing for both the original and newly created windows.

#7	mike 17:54 Feb 05, 2005

Reassigning to 2.0...

#8	pgriddev.yahoo 05:44 Feb 17, 2005

I ran accross similar issues, and have a quick workaround for FLTK-1.1.x on win32 (5 lines to change). It might work under X as well (probably with even less changes), but I haven't tested it. Here is a 'diff -uw' based on FLTK-1.1.6 in fl_ask.cxx: prevent 2nd popup from showing up until 1st is closed ============== @@ -56,6 +56,7 @@ static Fl_Window *makeform() { if (message_form) { + while (message_form->visible()) Fl::wait(0.1); message_form->size(410,103); return message_form; } in fl_win32.cxx: workaround Windoze multithread peculiarities... ================ > some (tentative) explanation for the 2 changes below was posted to fltk.bugs under "modal windows will causedeadlocks in multi-threaded app" @@ -1064,6 +1064,9 @@ } parent = 0; + if (w->modal()) { + parent = 0; + } else if (w->non_modal() && Fl_X::first && !fl_disable_transient_for) { // find some other window to be "transient for": Fl_Window* w = Fl_X::first->w; @@ -1198,7 +1201,7 @@ } else { // Once again, we would lose the capture if we activated the window. if (IsIconic(i->xid)) OpenIcon(i->xid); - if (!fl_capture) BringWindowToTop(i->xid); + if (!fl_capture) SetForegroundWindow(i->xid); //ShowWindow(i->xid,fl_capture?SW_SHOWNOACTIVATE:SW_RESTORE); } } There is also a discussion about fl_ask (from a different angle) in STR #334. I'm hopping that Fl::wait() *can* be called from several threads, after all that's what we have Fl::lock()/Fl::unlock() for. The fix above shows that some issues are definitely due to blocking Win32 calls (I admit, don't know about Linux/X, and I don't have the win32 modal window issue entirely figured out).