* 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
> :feeling that it should be significantly better. [Again, under
> :3.4-release.] I don't think I've done anything egregious, but things don't
> :seem much better. Unfortunately, I'll have to wait until tomorrow morning
> :to rip things out and make a suitable example program for posting.
> :
> :Actually, the performance profile does seem different (for lower loads, the
> :semaphore solution seems more efficient), but the performance limits seem
> :much the same between the single socketpair and semaphore versions when I
> :starts using 16-20 worker processes. It's possible that I'm doing
> :..
> :
> :Thanks,
> :scott
>
> Well, when all else fails --- go back to individual pipes.
>
> What else could be tried... you could try surrounding the read()
> with an flock() pair. I don't know if flock() uses the more optimal
> wakeup code or not.
It doesn't, it wakes all processes blocking on the lock, the flock case
could be optimized but doesn't seem to be.
I think you probably want to experiment with pools attached to the
pipe, and you ought to be using pipe rather than socketpair. Meaning
have a group of children share a pipe, but not more than N, where N
is where you start to see performance problems.
-Alfred
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
