Re: (e)poll takeover

[Hans Henrik Happe]

On Wednesday 28 June 2006 18:05, you wrote:
> > Hi
> >
> > I have tried to find a way to have a thread take over the event waiting 
from
> > another thread. This should be done without context switching.
> >
> > A more precise description:
> >
> > 1. Thread A are waiting in poll or epoll.
> > 2. Thread B decides to take over the waiting. This means stopping thread A
> > from responding to new events and go into a (e)poll for the same events.
> > 3. After handling some events thread B decides to let thread A take over
> > again.
> 
> 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"?
 
> other than that, put a loopback "control" pipe in the interest set, wake
> up thread A via a write to the pipe, let it block and wake it up later by
> whatever mechanism you like (conditionals,...) once thread B is finished
> handling events

Then I'll get a context switch.

> you could try doing more elaborate things with pthread_kill, custom signal
> handlers and sigsetjmp to get thread A out of the polling loop, but I
> don't think any of this will be more efficient than a control pipe
> 
> as for avoiding a context switch on 3... just postpone waking up the
> thread as soon as you can tolerate a context switch

The problem is that I don't know when this is.

> (is this some real-time thing?)

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. 

> 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.

Hans
-
To unsubscribe from this list: 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