I have created a new branch felix-1.1.10, reversioned the head 1.1.11,
and merged RF's flx_world branch into the head.
There may be bugs in it since the very top level startup code
has been refactored so that it will be possible shortly I hope
to embed Felix like this:
// get felix running
world = create(..);
startup = mystuff();
// run felix until it blocks on external event
world.run(startup);
// calculate an idle handler
idle_handler = world.idle_handler();
// create your other event loop
el = other_event_manager();
// set the idle handler of that loop
// the wrapper is dependent on your loop's requirements
// the idle_handler is the client data void * passed to it
el.set_idle_callback (idle_wrapper, idle_handler);
// run the other event loop
other_event_loop();
Basically, felix will run until it would currently lock up waiting for
an external event such as a timeout, socket to become ready, etc.
But with this architecture it doesn't block, it returns instead.
Now you run your other event loop. When it has done everything and
would block itself, it will typically call any client supplied idle_handler
before looping about (possibly with a delay before relooping).
That idle handler callback you must write for your loop's requirements.
It will take the void *client_data pointer and cast it to a Felix
entity which can then be passed to the world object as a continuation:
It will then do a world.run on that object which will again run Felix
until it would block, and then return.
If you use Felix alarm clock or socket I/O, Felix code will eventually
continue on. So basically the other event loop and Felix will exchange
control via this mechanism.
There will also be a way to create new kinds of events. For example
if you're running a game under SDL, and you want Felix to handle
keyboard events, your SDL main loop will fetch the event, and it will
then send it to Felix by servicing a request for keyboard events the
Felix code made.
Basically you have to write code which causes the pending request
to go back in the "waiting to be rescheduled queue". Felix will then
pull the fibre off that queue, and put it on the synchronous scheduler
and run it.
To do that you must service the event by storing the keycode where
it is expected, and removing the fibre waiting on it from the schannel
on which it expects to read it. This simulates the schannel operation.
Exact details of creating your own events will follow.
When we figure it out :-)
In general, you can "strobe" the Felix system in any callback.
So in a windowing system, in any of the events associated with
a GUI requiring a callback, you can run a bit more of the world.
In particular, inside the callback, you can transmit the event which
triggered the callback to Felix and allow Felix to handle it.
In short, you will be able to escape reactive programming hell,
and switch to a more modern and sane paradigm using
fibres or coroutines, by implementing a control inversion bridge
for the master architecture.
So Felix is switching from architectural MASTER to architectural PEER.
--
john skaller
skal...@users.sourceforge.net
http://felix-lang.org
------------------------------------------------------------------------------
Managing the Performance of Cloud-Based Applications
Take advantage of what the Cloud has to offer - Avoid Common Pitfalls.
Read the Whitepaper.
http://pubads.g.doubleclick.net/gampad/clk?id=121054471&iu=/4140/ostg.clktrk
_______________________________________________
Felix-language mailing list
Felix-language@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/felix-language
