More specifically, I was wondering if the write to the pipe or the call back
into poll involved anything that might prompt the scheduler to replace the
thread in this scenario.
> It's reasonable to expect that this will be the most common case and the
> one to optimize. It is unreasonable to fail if this doesn't happen, since
> it's not guaranteed to happen. Note that if by "without a context switch"
> you really mean without another thread getting a chance to run, then it is
> totally unreasonable.
Are you referring to transitions to/from kernel space? If so, wouldn't the
write
on the pipe and the call to poll both result in transitions?
Regards,
Iker
----- Original Message -----
From: "David Schwartz" <[email protected]>
To: "Iker" <[email protected]>; <[email protected]>
Sent: Friday, September 12, 2003 10:04 PM
Subject: [lkml] RE: self piping and context switching
>
> > Assume a thread is monitoring a set of fd's which include both ends of
> > a pipe (using poll, for example). If the thread writes to the pipe (in
> > order to notify itself for whatever reason) is it reasonable to expect
> > that it will be able to return to its poll loop and get the event
> > without a context switch? (provided it quickly returns to the poll
> > loop).
>
> It's reasonable to expect that this will be the most common case and the
> one to optimize. It is unreasonable to fail if this doesn't happen, since
> it's not guaranteed to happen. Note that if by "without a context switch"
> you really mean without another thread getting a chance to run, then it is
> totally unreasonable. On SMP systems and with hyper-threading, threads can
> run concurrently.
>
> DS
>
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
> More specifically, I was wondering if the write to the pipe or
> the call back
> into poll involved anything that might prompt the scheduler to replace the
> thread in this scenario.
Sure, it could, but there's no particular reason to expect it to. The one
exception would be if another thread was already blocked waiting for that
particular pipe. In this case, your sending data on the pipe would unblock
that thread, which could trigger a pre-emption.
> > It's reasonable to expect that this will be the most common case and the
> > one to optimize. It is unreasonable to fail if this doesn't
> > happen, since
> > it's not guaranteed to happen. Note that if by "without a
> > context switch"
> > you really mean without another thread getting a chance to run,
> > then it is
> > totally unreasonable.
> Are you referring to transitions to/from kernel space? If so, wouldn't the
> write
> on the pipe and the call to poll both result in transitions?
Yes, but there's no reason that transition should cause the kernel to want
to change processes. The kernel generally tries to let processes complete
their timeslice. An exception could certainly be if the write to the pipe
causes a new thread to unblock and that that thread has a higher dynamic
priority (which it well might, since it was waiting).
Personally, I don't think the kernel should ever pre-empt threads/processes
with equivalent static priorities, but that's another whole argument. ;)
DS
On Sad, 2003-09-13 at 03:56, Iker wrote:
> More specifically, I was wondering if the write to the pipe or the call back
> into poll involved anything that might prompt the scheduler to replace the
> thread in this scenario.
Unless it happens to cause page faults or fill up the pipe nothing in
paticular. Sending a message to yourself down a pipe is pretty standard
in event based programs as a way of turning a signal from asynchronous
event and thus nuisance to handle into a message.
Alan Cox wrote:
> On Sad, 2003-09-13 at 03:56, Iker wrote:
> > More specifically, I was wondering if the write to the pipe or the call back
> > into poll involved anything that might prompt the scheduler to replace the
> > thread in this scenario.
>
> Unless it happens to cause page faults or fill up the pipe nothing in
> paticular. Sending a message to yourself down a pipe is pretty standard
> in event based programs as a way of turning a signal from asynchronous
> event and thus nuisance to handle into a message.
This "pretty standard" method is the reason Netscape 4.07 hangs on
computers which are too fast: It writes too many events to a pipe
before reading from the pipe, and the pipe fills.
Of course that is a programming error. Just a reminder to be careful :)
-- Jamie