FLTK logo

Re: [fltk.bugs] [LOW] STR #1536: a thread-related helper

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.bugs  ]
 
Previous Message ]New Message | Reply ]Next Message ]

Re: [LOW] STR #1536: a thread-related helper Michael Sweet Feb 12, 2007  
 
Yuri D'Elia wrote:
In article <5400-fltk.bugs-+FT6Wyec2gCDR8wcTNDzOQ@public.gmane.org>,
 Michael Sweet <mike-B9D8k9nSxTHQT0dZR+AlfA@public.gmane.org> wrote:

Nothing prevents the main loop code from processing multiple events
before calling the add_check() callback, and you don't know if that

Does it make any difference? They're not guaranteed anyway.

Also, you might want to use add_check() for something else, whereas
set_awake_cb() has but a single purpose.

I suppose we could go on forever on this, so I'll cut it short. To me, it still looks so splendidly useless. At least now awake() is nonblocking.

Maybe there's more we can discuss about FLTK 2.

Yes, we can revisit this for FLTK 2, at least from the standpoint of
changing the awake() function to return a boolean, and perhaps for
extending this to a true RPC (rather than IPC) mechanism.  However,
like I've said before I'm not keen on adding a complex, guaranteed
delivery system unless you can show it can be generally useful to
a broad range of multi-threaded apps.

--
______________________________________________________________________
Michael Sweet, Easy Software Products           mike at easysw dot com
Internet Printing and Document Software          http://www.easysw.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'.