I've only been looking for a day, Michael. I definitely see problems, though, and have already corrected some (though more testing is needed before distribution). I'm convinced the problems can likely be corrected in relatively short order...
Again, though, no truly stable operation can be ensured prior to understanding the threading model of the Radio and then coordinating the applet code with the operation of the underlying OS. The applet can't be properly fixed in a vacuum, without that broader system knowledge. The disparate threads either need to be guaranteed they'll run to completion respectively, or there *must* be some manner of synchronization provided by the OS which can be explicitly called by the applets to prevent re-entrancy during critical sections of code. There really is no middle ground... The bigger picture is that this issue transcends the AlarmSnooze applet problems. It applies to virtually all software running on the Radio. That is, if it's an issue at all (read: SqueezeOS may yet be forcing serialized applet execution through a single executive thread - I haven't had time yet to reverse engineer the underlying operation). Let's see what Logitech has to say about their threading model and/or critical section locking provisions... 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
