| |
| |
On 4/17/21 2:25 PM Michael Sweet wrote:
Another crazy option: just have Fl::lock() be a no-op if the run loop is not active and then have Fl::run() call Fl::lock() unconditionally. When threading is enabled (which should be all the time now) the right thing happens without any special initialization, and Fl::lock()/unlock() can continue to be used for synchronization as before.
The new (1.4) code examples can explain this change and existing code will continue to work.
Mike and others,
I thought again about your suggestion. Although I'm sure that we must
not make Fl::lock() and Fl::unlock() no-ops if the run loop is not
active this model could still work *if* we wanted to enable locking
*unconditionally* in all FLTK applications.
(1) Fl::lock() and Fl::unlock() must always be functional, even before
Fl::run() is called.
(2) We increment and decrement our own internal lock counts in
Fl::lock() and Fl::unlock(), resp.
(3) At the entry of Fl::run() we check if Fl::lock() is effective
(internal lock count > 0) and if not, call Fl::lock() internally only
once when Fl::run() starts the loop.
(4) The internal unlock/wait/lock mechanism would not need to be changed
but would always be effective, even in single-threaded programs.
This way old code that calls Fl::lock() works as before and code that
does not call Fl::lock() would still use unlock/lock internally and
could use threads with FLTK locking etc.
That said, I think it's possible to do, but I'd still vote for leaving
everything as-is, i.e. do not force single-threaded apps to do internal
locking.
--
You received this message because you are subscribed to the Google Groups "fltk.coredev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to fltkcoredev+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/fltkcoredev/d72fb06d-9bb6-f503-e07b-a7b7cf70f0c3%40online.de.
[ Direct Link to Message ] | |
|
| |
