matthiasm wrote: > > On Mar 6, 2007, at 7:13 PM, Michael Sweet wrote: > >> [email protected] wrote: >>> Author: matt >>> Date: 2007-03-06 12:15:03 -0500 (Tue, 06 Mar 2007) >>> New Revision: 5729 >>> Log: >>> This is a suggested change. It is complete except for documentation. >> >> Um, can we discuss these changes before making them? > > Yes, I normally would. If you don't like it, I'll reverse the SVN.
No, your implementation is simple enough, doesn't grow without bounds, and allows us to add a status code for the delivery so the caller knows whether the RPC call was queued... Yuri was also asking for this sort of API as well, so I'll take that as enough reason to keep it in. My objection was more a matter of not expecting the thread messaging API to change again... :) >> One of the >> reasons I didn't go for a memory-queued RPC approach was because >> of the added locking and memory usage... > > 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... :) > ... > 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... -- ______________________________________________________________________ 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
