I admit to being a novice here at the Squeezebox forums, so I may not be entirely up to speed on the proper etiquette for addressing the Logitech development organization. I apologize in advance if this is the wrong place for this post.
Having said that, it would help me greatly (and perhaps many other Radio adopters) if you guys at Logitech could answer a specific question about how the Radio operates under the covers... Some history: I've spent the day testing and examining the AlarmSnooze applet and now understand why it is seemingly so unstable (I also see what are likely to be instabilities in the newest version of the applet, which I also tested). The underlying reasons for the instability of this applet may also bear a relationship to why the Radio seems to exhibit instability in other respects. Without going into too many specific details on the AlarmSnooze applet (so as not obscure the forest for the trees), I see what appears to be a glaring hole in the operation of Radio applets in general. Now, it may be that since I don't fully understand the underlying Radio infrastructure at this point I am missing something. I've only been studying Radio applet operation for one day now (albeit all day), but I'm very surprised at the general nature of the applets I've reviewed (in particular, AlarmSnooze). Please keep in mind that I really don't mean to appear presumptuous... with that said, it appears to me that the Radio is using Lua in a multithreaded manner (seemingly using LOOP packages). I gleaned that asynchronous event notifications can be delivered to applets; for example I see that the playerConnected and playerAlarmState notifications are registered by the AlarmSnooze applet. It also appears that timers provide for a separate callback mechanism when they expire and subsequently invoke the applicable registered callback function(s). I looked long and hard for either a critical section directive, or a semaphore or mutex provision but was unable to find one. I searched at both the Jive level and lower at the Lua proper level. I did locate some locking mechanisms specified in the Lua documentation amongst the Lua language extensions, but I don't see any use of, or provision for, them on the Radio after extensive searching. I haven't had the time yet to explore SqueezeOS in depth, but I'm curious if you guys are using a run-to-completion, timesliced, or preemptive threading model on the Radio...? Or are you forcing some other manner of simulated single threaded operation by funneling all disparate looking thread contexts through a single monolithic executive thread of some type...? In a nutshell, are you running a truly multithreaded environment? And if so, how do you have the scheduler configured? If there are really disparate threads (for example, the notification callback subsystem and the timer subsystem) that can invoke applet functionality from their own distinct contexts then there either needs to be forcible synchronization/serialization of applet threads by the underlying OS scheduler (perhaps run-to-completion) or there needs to be some critical section, semaphore, or mutex type operation(s) available for applets to explicitly provide for code synchronization where applet resources are shared amongst functions. I see specific spots in the AlarmSnooze applet (which I'm certain can be extrapolated to many other pieces of software on the Radio) where disparate underlying system thread contexts can crash into (preempt) each other because there is no overt means of locking a particular section of code against said preemption... As I'm guessing you guys know, multithreaded embedded systems typically use a variety of synchronization mechanisms to prevent these types of problems when information needs to be coherently shared amongst more than one thread of execution. If you guys have a critical section mechanism (or mechanisms) under the covers somewhere then can you please point them out...? Thanks very much, and kudos on all your hard work on the very cool Squeezebox products. Marc p.s. I believe I have hardened up the latest release of the AlarmSnooze applet, but until I understand how the underlying scheduler and threading model works I do not believe that the applet (and perhaps others) can be properly modified to be entirely stable. -- 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 Radio@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/radio
