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