* Christopher Key shaped the electrons to say...
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.
Not quite. 1) We're requiring perl 5.8 or higher (preferably 5.8.3) for 6.5 2) split-scanner does not use threading - it simply spawns a separate process using Proc::Background (which does the right thing on Windows & *nix) 3) Those were thoughts for version 7. Nothing is set in stone. At this point in time, FastCGI is likley a better alternative than mod_perl, and that's still a big "if we decide to use Apache".
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.
For purposes of our conversation, "thread" should really be "multiple processes", as Perl's threading and DBI (the database abstraction layer) don't mix so well. Separate processes are nice, and they gain COW semantics, as well as isolation that threads don't afford.
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.
One of the big blocking points with Apache is that it doesn't support UDP, which is what the old SliMP3 protocol uses. If we are to maintain backwards compataiblity for that product, we need a solution for UDP. Again, Apache is only one solution. For the time being, assume we are sticking with Perl - we have a large codebase of it already, and good knowledge. Other solutions in the same ballpark of re-architecture include: *) POE *) Event::LibEvent Which both provide async methods of handling data in and out. Both require a pretty large rework of how the current code base is written. Now is the time to be discussing this. Writing code is even better. :) -D -- <jwb> "I am POWERBOOK thy god. Thou shalt have no other laptop before me" <gage> and the mountains shall drop sweet wine, and the hills shall melt _______________________________________________ beta mailing list [email protected] http://lists.slimdevices.com/lists/listinfo/beta
