Re: signals and atomicity
erikyyy@studbox.uni-stuttgart.de 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 <rlb@cs.utexas.edu>
PGP fingerprint = E8 0E 0D 04 F5 21 A0 94 53 2B 97 F5 D6 4E 39 30
--
To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Reply to: