On Tue, Jan 25, 2000 at 09:12:31AM -0800, Brian D. Moffet wrote:
> Okay, stupid question. socketpair returns 2 sockets which according to
> the man page are "indistinguishable". Does this mean that you can read and
> write to either socket pair?
Yes sir.
> pipe(2) returns 2 file descriptors,
"Alfred Perlstein" <[EMAIL PROTECTED]> wrote:
> I think you probably want to experiment with pools attached to the
> pipe, and you ought to be using pipe rather than socketpair.
My tests indicate that pipe performance in this case is identical to
socketpair performance. Perhaps because I'm sendi
Okay, stupid question. socketpair returns 2 sockets which according to
the man page are "indistinguishable". Does this mean that you can read and
write to either socket pair?
pipe(2) returns 2 file descriptors, one of which is a read and one of
which is a write fd. The other end flips these a
* Matthew Dillon <[EMAIL PROTECTED]> [000125 11:51] wrote:
>
> :OK, so let's say I did spend some time implementing it in terms of semget()
> :and semop(). Would you be totally apalled if the performance turned out to
> :be about the same as using a single socketpair? Do you have a very strong
"Brian D. Moffet" wrote:
> Okay, stupid question. socketpair returns 2 sockets which according to
> the man page are "indistinguishable". Does this mean that you can read and
> write to either socket pair?
Yep, you can write to either end and it will come out the other end.
> pipe(2) returns
:OK, so let's say I did spend some time implementing it in terms of semget()
:and semop(). Would you be totally apalled if the performance turned out to
:be about the same as using a single socketpair? Do you have a very strong
:feeling that it should be significantly better. [Again, under
:3.
"Scott Hess" <[EMAIL PROTECTED]> wrote:
> "Matthew Dillon" <[EMAIL PROTECTED]> wrote:
> > :Unfortunately, I've found that having a group of processes reading
> > :from a group of socketpairs has better performance than having
> > :them all read from a single socketpair. I've been unable to
> > :
"Matthew Dillon" <[EMAIL PROTECTED]> wrote:
> :Unfortunately, I've found that having a group of processes reading from
a
> :group of socketpairs has better performance than having them all read
from
> :a single socketpair. I've been unable to determine why.
>
> The problem is that when you ha
Brian Somers wrote:
> > "Scott Hess" wrote:
> >
> > > I've found an odd performance issue that I cannot explain. I'm using
> > > socketpairs to communicate with multiple rfork(RFPROC) processes.
> >
> > Use 'pipe(2)' rahter than 'socketpair(2)' as both are bidirectional and
> > pipe is a LOT fa
> "Scott Hess" wrote:
>
> > I've found an odd performance issue that I cannot explain. I'm using
> > socketpairs to communicate with multiple rfork(RFPROC) processes.
>
> Use 'pipe(2)' rahter than 'socketpair(2)' as both are bidirectional and
> pipe is a LOT faster.
Although pipe(2)'s bi-direc
"Scott Hess" wrote:
> I've found an odd performance issue that I cannot explain. I'm using
> socketpairs to communicate with multiple rfork(RFPROC) processes.
Use 'pipe(2)' rahter than 'socketpair(2)' as both are bidirectional and
pipe is a LOT faster.
Cheers,
-Peter
To Unsubscribe: send ma
:I've found an odd performance issue that I cannot explain. I'm using
:socketpairs to communicate with multiple rfork(RFPROC) processes.
:Initially, I used a seperate socketpair to communicate requests to each
:...
:
:Unfortunately, I've found that having a group of processes reading from a
:gro
I've found an odd performance issue that I cannot explain. I'm using
socketpairs to communicate with multiple rfork(RFPROC) processes.
Initially, I used a seperate socketpair to communicate requests to each
process, with locking in the parent to synchronize access to each client.
I determined tha
13 matches
Mail list logo
