Hi Hans,
Hans-Christoph Steiner wrote:
Threading is not the only way to do concurrency. Think of all of those objects in your patch, they are all running in parallel.
Yes, there's other ways than threading. ligthttpd and HAProxy are good examples of monolithic state machine that can serve thousands of requests per second. But in some respect, they are much more simple projects than pd.
From HAProxy "design choices"
=== HAProxy implements an event-driven, single-process model which enables support for very high number of simultaneous connections at very high speeds. Multi-process or multi-threaded models can rarely cope with thousands of connections because of memory limits, system scheduler limits, and lock contention everywhere. Event-driven models do not have these problems because implementing all the tasks in user-space allows a finer resource and time management. The down side is that those programs generally don't scale well on multi-processor systems. That's the reason why they must be optimized to get the most work done from every CPU cycle. ===
The big difference is that you don't care is HAProxy if something takes 10us more.
In pd, a object like soundfiler blocks everybody else *long enough* so you can ear it, *unless * you do the hard part, that is, time slicing.
My point is that it's really really hard to write solid threaded code (that surely is a reason for pd being monoprocess in the first place). So I find it strange that pd lets it to the user. Yes, having a 4-core CPU and getting clicks in audio when you load a sample in an array is hard to swallow in 2011 ;).
And you had to do nothing to make sure that they run in parallel, don't block each other, sync up, etc.
That's the point of the discussion. A single threaded state machine is not a multi-threaded process, where time-splicing occurs at the kernel level.
Ok, so now I'm just complaining, and I can't write a threaded audio engine just yet... So, fork() it ;).