On Sat, 9 Jun 2001, Paul Davis wrote:
i had a couple of hours today to work on the multiprocess
audioengine. its now doing its basic tasks of starting a server on a
socket, accepting new connections from clients, waking periodically
from poll(2), telling its clients to do some work, etc.
In message [EMAIL PROTECTED]you write:
Paul Davis wrote:
I don't understand of what you're speaking: in my design for multi
process model the switch back to the engine happens only once for each
period (as it's needed).
Yes, but thats because your example didn't solve a rather fundamental
Note that here you doubled the cost compared to a pull model (you would
i don't understand. how has this doubled the cost? i know there
is extra cost from supporting multiple processes, but i don't
see an algorithmic doubling in the model. can you explain?
call it that way? I.e. I'm
On Mon, 11 Jun 2001, Paul Davis wrote:
I'd like to see how you are using kill (i.e. how do you do callback
operation between a manager and a process at all!??).
client (within a library call):
sigwait (signals, sig);
switch (shm_control_block-event) {
case
On Mon, 11 Jun 2001, Paul Davis wrote:
Ok, thats code I understand. How is this different from the GLAME
approach which does (same scope as your example):
client (within a library, wrapping up a callback like operation)
read(inputportfd, control, 4);
switch (control-event) {
but what happens when this particular client is now supposed to run
later in the graph? how does inputportfd and outputportfd get reset to
point to the correct next client ?
You have the same race with your approach - just doing the forward
from the client does not work if f.i. the supposed
Paul Davis wrote:
Note also that signals may have some non atomicity troubles.
such as?
Go to sleep *after* signal has been received (same problems that's faced
with pthread_cond_wait semantic).
Nope. sigblock/sigsuspend/sigpending take care of that.
As I said to Richard, I
On Mon, Jun 11, 2001 at 02:02:15PM -0400, Paul Davis wrote:
[pipes vs signal]
what does anybody else think?
I prefer signals, they just seem simpler and more portable.
- Steve
Paul Davis wrote:
i had a couple of hours today to work on the multiprocess
audioengine. its now doing its basic tasks of starting a server on a
socket, accepting new connections from clients, waking periodically
from poll(2), telling its clients to do some work, etc. note that i
I don't understand of what you're speaking: in my design for multi
process model the switch back to the engine happens only once for each
period (as it's needed).
Yes, but thats because your example didn't solve a rather fundamental
problem of resorting the graph.
its easy to shuffle a set of
Paul Davis wrote:
I don't understand of what you're speaking: in my design for multi
process model the switch back to the engine happens only once for each
period (as it's needed).
Yes, but thats because your example didn't solve a rather fundamental
problem of resorting the graph.
It
i had a couple of hours today to work on the multiprocess
audioengine. its now doing its basic tasks of starting a server on a
socket, accepting new connections from clients, waking periodically
from poll(2), telling its clients to do some work, etc. note that i
short-circuited the design used by
12 matches
Mail list logo
