[EMAIL PROTECTED] writes: > i think the whole system is shit. it cannot work this way.
Nice temper. Not the best approach to getting help I've seen... > there is no single way to solve this problem with linux :-( i am very > unhappy. Apparently. > what is this good for ? well. threads communicate through message > queues. but B will not receive the message from A, if he is stuck in > a system call. so A calls signalthread_B, if it is possible, that B > ever gets locked in system calls. of course, ONLY system calls > marked as INTERRUPTIBLE may return EINTR. (otherwise one would have > to check the return code of EVERY system call. > > it is extremly important, that signalthread_B doesn't get lost, > i.e. B just doesn't get the EINTR. Relying on EINTR like this is just broken. If you're that concerned about thread B getting woken up, you should be much more careful about using any blocking system calls, and yes, you *must* check the return code of *every* system call. Aside from the fact that you need it here, not doing so is just bad programming. You should probably be using select with a timeout instead of a blocking read, and if responsiveness is *really* critical, then you may need to restructure your program so that one thread is handling IO, and another is catching communications from thread A and doing the time-critical operations. Alternately, and perhaps even better, you could have two fd's. One is the normal one you're waiting on for data, and the other is a control fd. Have thread B issue a (blocking) select on both of them, and if you need to wake B up immediately, don't use signals (which don't have the best semantics in the face of threads), just send a byte on the control fd. -- Rob Browning <[EMAIL PROTECTED]> PGP fingerprint = E8 0E 0D 04 F5 21 A0 94 53 2B 97 F5 D6 4E 39 30 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
