> > the most obvious thing, though probably not what you want...
> >
> > thread B:
> >
> > pthread_kill(threadA, SIGSTOP);
> > // handle events
> > pthread_kill(threadA, SIGCONT);
>
> I'll look into this. I guess that that poll() will return after SIGCONT with a
> EINTR "error"?
yes; problem is, you may catch threadA in an arbitrary context which may
or may not be what you want
perhaps sigprocmask and ppoll/epoll_pwait may help you further in this
case
[...]
> No, It's a latency thing in a distributed system. Basically thread B can both
> be I/O-bound and CPU-bound. In the first case I want to avoid context
> switching in order to minimize latency. In the later communication should
> continue (servicing/forwarding requests), while thread B is doing
> computation.
what about simply letting thread A/thread B race for event notification?
with epoll you can do that (with plain poll obviously you cannot...), and
you always get perfect latency (but you don't know which thread will
eventually handle the event)
> > however all that still begs the question why you don't just let the
> > threads swap roles
>
> The threads have very different call stacks. Also, this would not solve the
> context switching issues.
this is really whacky, but... you *could* use setcontext and friends to
switch to the other thread's call stack after returning from poll/epoll
(instead of taking over event waiting in the other thread) -- basically
you replace a kernel context switch with a user-space context switch
are you sure this kind of micro-optimization is really required in your
case? If one thread is compute-bound, the scheduler will usually do the
right thing
--
Helge Bahmann <hcb@xxxxxxxxxxxxxxx> /| \__
The past: Smart users in front of dumb terminals /_|____\
_/\ | __)
Wer im finally-Block sitzt, sollte nicht \\ \|__/__|
mit exceptions werfen. \\/___/ |
|
-
: send the line "unsubscribe linux-net" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
