:kern_subr.c can't do that, because `struct uio' doesn't give the original
:count.
:
:> Would you like to do it or should I? This isn't high priority but it
:> should definitely not be rescheduling after the first 96 bytes. That's
:> just a waste of cpu.
:
:The waste for rescheduling should be insignificant, since it should only
:occur every ROUNDROBIN_INTERVAL (default 100 msec). It actually seems
:to be rescheduling more often. Rescheduling _after_ the first 96 bytes
:is surprising, since the rescheduling is done before doing any i/o, so
:sync effects from sleep(1) should cause rescheduling before any i/o is
:done. Then the reader won't run, but other processes may.
:
:Bruce
sleep() is not relevant... what is relevant is that the sub-process
is doing a write() while the parent is sitting in a select() -- the
parent process is thus going to have priority over the child.
The moment the child allows a reschedule, the parent gets the cpu.
I would like to point out that this type of situation will occur with
most piping situations. The reader is almost always blocked waiting
to read while the writer is obviously always running, in the middle of
the write.
-Matt
Matthew Dillon
<dil...@backplane.com>
To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-current" in the body of the message
