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