bluegaspode;497583 Wrote: > I'm no Logitech-Developer so what I'm writing might be wrong. > I stumbled about the same things when I wrote an applet that used the > Timer-Framework a lot and I wondered about the same things > > As far as I remember there is a (Single-Threaded) Main-Event-Loop which > 'fires' all events (including Timer-Events). I'll try to find the > corresponding classes in the evening (I am at work right now) I think I > remember them lying around under the 'jive' package. > > I guess/hope that external events are queued as well so you won't have > 'real' multithreading in the LUA-Applets themselfes. > > As I said I found these places when following the Timer-System (was it > window.addTimer ??). > As the HTTP Framework also works asynchronious (receiving the > responses) you might also start there. The Flickr-Applet does > HTTP-Requests so its a good starting point for further investigations as > well.
Ok, I think I see how the system works, in general, now that I've looked further at Lua coroutines. An explanation (albeit, a bit confusing) is here: http://lua-users.org/wiki/CoroutinesTutorial I do see sporadic use of coroutine mechanisms in some of the jive and lua code on the Radio, though the explicit use of these coroutine mechanisms is not very widespread. So, it looks like the system is using cooperative scheduling in a run-to-completion model. That is, it appears each thread runs either to completion (without interruption) or until it explicitly yields to other threads in the system by calling coroutine.yield(...) Now, where an applet does not explicitly yield (AlarmSnooze does not do so anywhere in the applet) the question that remains is this: where, if anywhere, does the underlying jive (or lua proper) code implicitly yield during a system call of some kind that is made from the applet? The point is that the applet can still yield to other threads when it makes another system call (which is defined elsewhere) which itself calls coroutine.yield(...) I don't think this behavior (where system calls themselves yield under the covers on behalf of the calling thread) is widespread, since I don't see too much use of yield in the jive foundation classes. I'm going to presume for now that this implicit yielding does not occur... Ok, I've poked around some more and see how both the timer and notification callbacks work. The main handling loop is defined in the UI framework and both notifications (via processEvents()) and timer callbacks are handled serially. So, everything does indeed look good in terms of thread-safety. I should never have doubted the Logitech guys in the context of system thread safety! :) Now I feel comfortable continuing on in the hardening of the AlarmSnooze applet. I've got some stuff to do today, but should be able to work on it again later tonight. Is there any licensing issue with modifying and then redistributing a Logitech provided applet? I don't see any reference to licensing in the AlarmSnooze applet code itself... I'll report back once I've had a chance to further harden and test the applet. I'll likely need some people who are willing to do their own testing with it as well (once it's ready for that), since it's very unlikely that I'll be able to test all the code paths in my own environment. I will be certain to heavily instrument the first distribution for troubleshooting purposes so that when logging is turned up for the applet there will be little doubt about what has transpired in problem cases... Marc -- Marc ------------------------------------------------------------------------ Marc's Profile: http://forums.slimdevices.com/member.php?userid=34776 View this thread: http://forums.slimdevices.com/showthread.php?t=72871 _______________________________________________ Radio mailing list [email protected] http://lists.slimdevices.com/mailman/listinfo/radio
