kdf wrote: >> I've had a bit of a dig, but not found anything that seems to be >> conclusive. Could you point me in the right direction, as you know >> what you're looking for. > > http://forums.slimdevices.com/showthread.php?t=15613 > http://forums.slimdevices.com/showthread.php?t=1166 > http://forums.slimdevices.com/showthread.php?t=21984 > http://forums.slimdevices.com/showthread.php?t=14453 > http://forums.slimdevices.com/showthread.php?t=1348 > > and some of these refer to other threads that I haven't bothered to > dig up. > > If I've missed anything, I'm sure those involved would be more than > happy to reiterate or contradict their previous statements. >
Can I assume that the position is approximately as follows. It is agreed the splitting things up is certainly worthwhile, but that pre Perl 5.8, it really isn't practical, and requiring Perl 5.8 wasn't acceptable. Perl 5.8 introduced suitable threading, and the split-scanner is based upon this. The intention for version 7 is to move over to apache / mod_perl, which will make threading far easier. My view is that it would be nice to have multiple threads each serving requests seperately. I would envisage having one thread per connected squeezebox. SlimServer would create a suitable sized pool of such threads when it started, and each would be allocated a squeezebox to serve as they connected. This way, the user interface would always feel responsive, and would hopefully prevent stuttery scrolling, poor time display etc. Any code that does something slow would only block the user interface actually calling that code, and would leave other users unaffected. The option of whether to update this code to work asynchronously could then be made based upon whether blocking, and the time delay was acceptable, rather than having to ensure that no code ever ran for an unnacceptable time. One could for example choose to dispatch a thread to perform the database lookups on track listings, whilst allowing the user to cancel before the lookup completed. Similarly, the web interface would have a pool of threads, each serving requests, as would the CLI. Finally, there would be a low priority thread resposible for maintaining the database and keeping it up to date, and scanning as required. As an aside, it struck me that it might be quite nice to have the scanner build up a completely new database content during a rescan. Only when the rescan completed would the new content be used, so that performing a rescan could be done slowly with very low priority, without affecting the user too much. The model above is I believe how most servers operate, certainly Apache, MySQL etc, and seems quite sensible. From what I've understood of the Perl threading system, this isn't too hard to implement, although converting SlimServer would be very much tougher. I've tried to do some research on how Apache / mod_perl work, and it looks like this solution would effectively implement what is detailed above. Apache would create threads to deal with each SlimProto connection request, and would obviously do the same with web requests. I presume that it would also be possible / desirable to have apache create a separate thread to serve each stream request. Chris Key _______________________________________________ beta mailing list [email protected] http://lists.slimdevices.com/lists/listinfo/beta
