That looks correct to me, but you should do connect_queue as well. You
should be guaranteed that the queues are empty (length 0) by the time you
get there (because anyone on the queue would hold a ref to the sock). But
it wouldn't hurt to have an assert in connq_destroy. (cq->queue might
still
Hi,
looks like a memory leak in pfinet, but I have not tried to find a test case
or test the fix (I am currently very busy, sorry), so I am not checking it
in right away.
Listen queues (and the queue array they contain) are possibly created but
nowhere destroyed.
Thanks,
Marcus
diff -ru pfloca
On Fri, Feb 09, 2001 at 05:58:33PM +0200, Eray Ozkural (exa) wrote:
> Well he said performance is not really an issue,
Sorry, but I must insist to be pedantic here. I said that performance is not
a concern, not that it is not an issue. Performance is very important, but I
don't think one needs to
On Sat, Feb 10, 2001 at 04:15:16PM +0200, Eray Ozkural wrote:
> On Sat, Feb 10, 2001 at 03:12:46PM +0200, Ognyan Kulev wrote:
> > One beautiful solution will be batching many IPC requests in one context
> > switch, e.g. (open,read,close).
>
> You mean a burst transfer. That's done in parallel pr
On Sat, Feb 10, 2001 at 03:12:46PM +0200, Ognyan Kulev wrote:
> One beautiful solution will be batching many IPC requests in one context
> switch, e.g. (open,read,close).
You mean a burst transfer. That's done in parallel programming. Many high
level libraries take advantage of that. It is ultim
On Fri, Feb 09, 2001 at 04:11:19PM +0100, Marcus Brinkmann wrote:
> Of course, but any message passing only adds a constant overhead to a single
> message. Performance increase can also be achieved by adding new interfaces,
> which remove the need to send several messages (by replacing them with a
