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 this
> 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
subsystems.

Proper design would design an event-loop so that
(a) the user can provide it with additional things to be done during
each loop
and/or
(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
frequently.

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@iro.umontreal.ca
https://webmail.iro.umontreal.ca/mailman/listinfo/gambit-list