I personally find your disdain for threads antiquated and naive
This shows a lack of understanding. It's like saying that the designers of a bullet train have a "disdain" for air transportation, or conversely that the designers of an aircraft have a "disdain" for rail transport. On the contrary. We are talking about two completely different computation models, each with their pros and cons.
I have been programming with threads since the mid 1980s - but for the LIVE555 libraries, I chose a single-threaded event-driven model instead. This works well for the type of applications that these libraries are typically used for, especially given that lots of inexperienced programmers (far more than I had originally anticipated, actually) are using the software.
If anyone is interested in this topic, I encourage them to view Professor John Ousterhout's slide presentation: http://www.softpanorama.org/People/Ousterhout/Threads/tsld001.htm (Personally, I wouldn't state the conclusion quite as strongly as he does, but - as a very experienced threads programmer myself - I agree with the general argument.)
BTW Have you ever encountered anyone that has ever successfully implemented a TaskScheduler that was multi-threaded?
In principle, it would be possible to replace the "event loop" with an "event pool" that contains events (tasks) that could be claimed and acted on concurrently by multiple threads (i.e., with each thread claiming and acting on a single event (task) at a time). This would not, however, eliminate potential problems with concurrent access to shared data structures - so programmers (especially inexperienced programmers) would still likely run into problems there. (Plus, problems might arise from having events being handled in an unexpected and non-deterministic order.) So, the "multi-threaded event pool" would be a different computation model again from the existing "single-threaded event loop" - and one that it's unlikely that I would support, absent a complete redesign of the whole software.
-- Ross Finlayson Live Networks, Inc. http://www.live555.com/ _______________________________________________ live-devel mailing list live-devel@lists.live555.com http://lists.live555.com/mailman/listinfo/live-devel
