We also use parts of pyglet for psych. research applications. We use Stackless Python to get coop threads / tasklets. I have no idea what the pro's / con's between it and fibra are for your application.
We also continue to NOT use app.run and instead manage our own event loop, as described in: http://www.pyglet.org/doc/programming_guide/dispatching_events_manually.html Since we also want immediate (sub millisecond) access to realtime inputs like TTL and the old fashions polling approach (while using more CPU) results in better access delay and lower variability. This is our experience at least. One nice thing about these dual / quad core CPUs that now seem to be the norm is that even with a polling app using 100% of one core, the rest of the OS seems happy with using the others, so you do not get the same hit on other app services as you used to with single core / cpu processors. On Feb 24, 5:51 am, "[email protected]" <[email protected]> wrote: > Can I just see if I understand these responses? > > With a function stack, it seems like it would be up to the > experimenter to reconceptualize their experimental procedure into a > series of production rules. If thats right, then I think it sinks this > idea, since it's unlikely that this target group will grok this. But > please let me know if I'm misunderstanding. > > The cooperative threading sounds interesting, I found fibra, but > couldn't find examples of tasks/tasklets. > Rob --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "pyglet-users" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/pyglet-users?hl=en -~----------~----~----~----~------~----~------~--~---
