[gambit-list] Gambit and event-based systems
euccastro at gmail.com
Thu Aug 7 12:57:08 EDT 2014
Yes, I'll add that my response was meant for *one* main-loop-hoarding
framework. If you need to use more than one of these, things get hairy
quickly and it's hard to make general suggestions without knowing the exact
APIs you're given.
On Thu, Aug 7, 2014 at 3:26 PM, Hendrik Boom <hendrik at topoi.pooq.com> wrote:
> On Thu, Aug 07, 2014 at 01:46:42PM +0200, Álvaro Castro-Castilla wrote:
> > Hi,
> > Specially in the mobile world, there are many platforms that force the
> > developer to think and code its applications around events. Sometimes
> > is done with virtual functions or interface implementation, overriding
> > methods, or plain C-style callbacks.
> > The problem is, in any of these cases, generally the main loop is
> > controlled by the application. Since Gambit runs within the
> > ___setup(params) function, and then quits (expecting ___cleanup() to be
> > called), there is no way to easily adapt to this architecture except for
> > running in a separate thread and communicating through messages or shared
> > data.
> > Is there a better way to do this?
> This is a fundamental flaw in event-loop systems -- that they have to
> take over control. And they are usually not designed with the
> understanding that the whole application might need two such
> Proper design would design an event-loop so that
> (a) the user can provide it with additional things to be done during
> each loop
> (b) There's a function that can be called that performs one iteration
> of the event-loop, so that the user can have a loop that calls it
> Even so, there are probably things that are difficult, such as avoiding
> busy-waiting. Sometimes separate threads are the best answer, if the
> synchronisation mecchanisms are fast enough.
> -- hendrik
> Gambit-list mailing list
> Gambit-list at iro.umontreal.ca
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Gambit-list