FLTK logo

Re: [fltk.general] Fl_Preferences instead of boost::interprocess

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 
 All Forums  |  Back to fltk.general  ]
 
Previous Message ]New Message | Reply ]Next Message ]

Re: Fl_Preferences instead of boost::interprocess Ian MacArthur Nov 17, 2021  
 
On Wednesday, 17 November 2021 at 15:15:38 UTC Matthias Melcher wrote:
Um (hi Ian, Bill ;-) , a few things:

1. threads have thread-local memory, but can still access the global space of the main thread. So if your main thread creates a Mutex, all children can access that thread. Just pass a pointer to the Mutex in the appropriate call.


Very true - indeed, unless you specifically ask for TLS (thread local storage) when you declare a variable in a global scope, the address space you get in every thread is basically the global address space of the main process, so "sharing" a mutex that way will typically Just Work.
In some ways, that's the key difference between threads and processes - threads have a shared memory context, processes do not.

 
2. FLTK should always be running in the main thread. You can call FLTK in child threads, but some platforms can not handle window creation or deletion outside of the main thread!

And by "some platforms" here we might well mean "most platforms", though things are changing... I always tend to assume "all platforms" at present as that makes the code reliably portable.
If you put the effort in, you can make GL contexts work "correctly" from the non-main threads but it can be tricky.
Other rendering paths... well, it's best to play it safe.
Particularly under WinXX, I have found it is very easy to create application code that *seems* to work Just Fine, and perhaps even does with some GPU drivers and etc., but then produces random corruptions elsewhere in the memory that are insanely hard to debug.
 

3. Just in case you plan to link FLTK to s dynamically linked library: You can not link FLTK statically multiple times in the same app. If you link FLTK (or any other library) dynamically once, you can't link it again statically.

Yes, I can't really see that working out -  This is under WinXX I think? Anyway, I think you'd need to build fltk as a DLL and use that, if there's a lot of other DLL's and they all want to interact with the fltk lib at runtime.


4. In a previous mail, I understood that you want to use the separate thread to download something across a network. If you want to notify FLTK in the main thread, that your library finished loading, you can use the sequence Fl::lock(); Fl::awake(handle_downloaded_data); Fl::unlock(); in your thread. This will call the handle_downloadPdata(void*) function in your main FLTK thread, which then can do UI stuff. Note: for FLTK locking to work, you must call Fl::lock(); once right before Fl::run();


And also: https://www.fltk.org/doc-1.4/advanced.html for more discussions on multi-threading with fltk.


--
You received this message because you are subscribed to the Google Groups "fltk.general" group.
To unsubscribe from this group and stop receiving emails from it, send an email to fltkgeneral+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/fltkgeneral/4fb84017-4092-460b-b0dd-1b246be1fdecn%40googlegroups.com.
Direct Link to Message ]
 
     
Previous Message ]New Message | Reply ]Next Message ]
 
 

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'.