| |
| |
On 4/17/21 4:36 AM, Albrecht Schlosser
wrote:
On
4/17/21 8:01 AM Greg Ercolano wrote:
While that's apparently the "right way" to
inform FLTK the app is going to use locking, it looks wrong and
feels wrong for app code to have a lock() without an unlock().
Well, there's no problem, you can also write
int main() {
..
Fl::lock(); // lock FLTK (this) thread
int ret = Fl::run();
Fl::unlock(); // unlock
return ret;
}
;-)
LOL, that just looks worse -- it looks like we're locking out
child threads from the entire app loop.
As
others have said already, I also wouldn't mind adding such a
function. Other method names might be:
Fl::start_lock();
Fl::use_lock();
An alternative and IMHO clean way to clarify things would be to
add an optional argument to Fl::run():
static int Fl::run(int enable_locks = -1) {...}
Oh, that's an interesting idea.
But hmm, what if there's other features we need to enable in the
future? Add them as arguments too?
Might be better to be a separate method with the name 'lock' in
it, so it can appear
in the threading docs along with the other lock related methods.
Another option might be to use Fl::option(ENABLE_LOCKING);
The more
I think about it, the more I like the latter, i.e. adding such a
parameter to Fl::run().
And FLTK 1.4 would be a good place to start this...
I like the idea if C++ supported named arguments like in python,
e.g.
Fl::run(enable_locks = 1);
But to just have:
Fl::run(1);
..seems unclear offhand. I'm trying to propose something so
the code reads clearly
what it does without comments.
--
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/61e7d815-145a-08ae-f988-8c57b60bd204%40seriss.com.
[ Direct Link to Message ] | |
|
| |
