Re: signals and atomicity

[erikyyy@studbox.uni-stuttgart.de]

On Sat, 18 Apr 1998, Herbert Xu wrote:

> In article <[🔎] Pine.LNX.3.96.980417092907.398C-100000@vulcain.yyydom> you wrote:
> 
> > if the signal occurs after the wait system call, but before the result of
> > the system call is stored in "wait_or_timeout_retval", the fact, that
> > the system call succeeded is lost.
> 
> > this is (1) a bug in apache and (2) a problem of me that i want to solve.
> > i thought others would have solved it, but this is obviously not true :-(
> 
> This should work:
> 
> static int wait_or_timeout_retval = -1;
> 
> static void alarm_handler(int sig) {
> 	errno = ETIMEDOUT; 
> }
> 
> int wait_or_timeout (int *status) {
> 	struct sigaction act;
> 
> 	wait_or_timeout_retval = -1; 
> 
> 	sigaction(SIGALRM, 0, &act);
> 	act.sa_handler = alarm_handler;
> 	act.sa_flags &= ~SA_RESTART;
> 	sigaction(SIGALRM, &act, 0);
> 	alarm(1);
> 	wait_or_timeout_retval = wait(status);
> 	alarm(0); 
> 	return wait_or_timeout_retval; 
> }

i do not think, this works.

alarm() calls setitimer(). setitimer() modifies "errno".
so, setting errno inside the signal handler does not work, i think.


i think the whole system is shit. it cannot work this way.

there is no single way to solve this problem with linux :-( i am very
unhappy.

again, this is what i want:

thread A: calls signalthread_B. must return IMMEDIATELY.
thread B: IF it just is inside a system call, this call must return EINTR.
          IF not, the NEXT system call that is marked as INTERRUPTIBLE
            (however this works) must return EINTR.

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.

byebye
Erik


--
EMAIL: erikyyy@studbox.uni-stuttgart.de                  \\\\
       thieleek@tick.informatik.uni-stuttgart.de         o `QQ'_
IRC:   erikyyy                                            /   __8
WWW:   http://wwwcip.rus.uni-stuttgart.de/~inf24628/      '  `
       http://tick.informatik.uni-stuttgart.de/~thieleek/


--
To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org