No subject

===
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 ;).


-- 
Charlot