Mon Sep 19 10:14:28 CEST 2011
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
The big difference is that you don't care is HAProxy if something takes
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
Ok, so now I'm just complaining, and I can't write a threaded audio
engine just yet... So, fork() it ;).
More information about the Pd-list