STR #675

FLTK matrix user chat room
(using Element browser app)   FLTK gitter user chat room   GitHub FLTK Project   FLTK News RSS Feed  
  FLTK Apps      FLTK Library      Forums      Links     Login 
 Home  |  Articles & FAQs  |  Bugs & Features  |  Documentation  |  Download  |  Screenshots  ]
 

Return to Bugs & Features | Roadmap 2.0 | Post Text | Post File | SVN ⇄ GIT ]

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 ]
Name/Time/Date Filename/Size top right image
 
#1 ramsdell
05:09 Jan 31, 2005
thr.cpp
2k
 
 
#2 pgriddev.yahoo
05:54 Feb 17, 2005
[fltk_bugs] FLTK v1_1_4 (win32) - modal windows will cause deadlocks in multi-threaded apps (1).txt
2k
 
 
#3 pgriddev.yahoo
05:54 Feb 17, 2005
[fltk_bugs] FLTK v1_1_4 (win32) - modal windows will cause deadlocks in multi-threaded apps (2).txt
1k
 
bottom left image   bottom right image

Trouble Report Comments:

Post Text ]
Name/Time/Date Text top right image
 
#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).
 
bottom left image   bottom right image

Return to Bugs & Features | Post Text | Post File ]

 
 

Comments are owned by the poster. All other content is copyright 1998-2024 by Bill Spitzak and others. This project is hosted by The FLTK Team. Please report site problems to 'erco@seriss.com'.