Dan Sully wrote: > 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. >
>From what I've read, threads look very much more straightforward to implement, as resources etc. can fairly readily be shared between them, and there is no need to implement any form of IPC. Would there be a significant amount of work involved in making the DBI thread safe? Would it instead be possible to write wrappers around non threadsafe modules that simply passed requests on to a single thread using that module. Slow operations using that module would block other requests to that module, but not everything else the system was doing. If that were a problem, the module could always be used asynchronously. The technique of having separate threads/processes serving each user seems intuitively quite nice, and would remove the need to implement 'manual' multitasking by repeatedly calling idleStreams. Even when the system is idle, I notice somewhat jerky scrolling. I strikes me that requiring no section of code to take longer than 140mS to execute seems a bit onerous, and arguably adds unnecessary complexity. >> 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. > Just a though, assuming the protocols are fairly similar, could a simple perl script be written that acted as a proxy between the two? > 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. :) > _______________________________________________ beta mailing list beta@lists.slimdevices.com http://lists.slimdevices.com/lists/listinfo/beta
