matthiasm wrote: > > On Mar 6, 2007, at 9:19 PM, Michael Sweet wrote: > >> My objection was more a matter of not expecting the thread >> messaging API to change again... :) > > Oh, got'ya. > >>> Yes, I thought about that. As for the memory, the buffer does not get >>> allocated unless you actually use this feature. >> >> Right, that's one of the things I like about your implementation >> (that and using the ring buffer, which takes me back to my old >> real-time programming days... :) > > Hah, I've been updating some PIC microcontroller code recently. When you > have 2k of ROM and 105 bytes of RAM, you learn to save. And I generally > love the concept of lazy evaluation. It matches my way of working. > >>> ... >>> Anyway, the current 'awake' system requires a number of crutches to work >>> well. Do you prefer that I finish the new code or should we reverse the >>> svn? I am fine with either and just make my stuff into a patch... . >> >> Please finish the new code (and documentation) - you just need to >> add the mutex stuff to make it work cleanly, everything else looks >> just fine to me... > > I committed the new locking already and I update my test process now. > > Do you want to keep "Fl::set_awake_cb()" API? It is way better than the > "Fl::wait(void*)" API, but may be confusing as a third API?!
Fl::wait(void *)??? Let's kill Fl::set_awake_cb() and stick with the RPC approach which is more general-purpose. Fl::awake(void *) can be documented as a "set a flag" type of API, where losing values is not problematic. Fl::awake(Fl_Awake_Func, void *) can be the "reliable" RPC mechanism for threaded apps. -- ______________________________________________________________________ Michael Sweet, Easy Software Products mike at easysw dot com Internet Printing and Document Software http://www.easysw.com _______________________________________________ fltk-dev mailing list [email protected] http://lists.easysw.com/mailman/listinfo/fltk-dev
