Re: signals and atomicity
On Thu, 23 Apr 1998, Herbert Xu wrote:
> In article <[🔎] Pine.LNX.3.96.980419122410.668B-100000@vulcain.yyydom> you wrote:
> > On Sat, 18 Apr 1998, Herbert Xu wrote:
> >> 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.
>
> That's easy to fix. Just store ETIMEDOUT in some other variable that is
> reset at the start of wait_or_timeout and store the result in errno if wait
> fails with EINTR.
this way you can fix the problem. but my initial problem was different:
2 processes. if (1) does a specific call (probably raising a signal), B's
next interruptible (whatever this means) system call must be interrupted.
the fact that (1) raised the signal mustn't get lost.
if you implement "interruptible" system calls this way:
1. UNBLOCK SIGNAL
2. SYSTEM CALL
3. BLOCK SIGNAL
it may happen that the signal handler is called just after unblocking the
signal but before the call. this way no EINTR happens, the signal is lost
and (2) is stuck in the system call.
because of this, i have to do a siglongjmp() in the signal handler.
now it isn't anymore possible that signals get lost. BUT ! i do not know
the return value of the system call, if it was interrupted.
remember, after the call , the signal is blocked again. now, if the call
succeeded, but still before the BLOCK SIGNAL command, if now again a
signal is received, siglongjmp jumps away, and the fact, that the system
call succeeded is just lost.
i am looking for an atomic way for a process to interrupt another
processes next system call, __that is marked as interruptible (whatever
this means)__. the interrupt __mustn't get lost__. afterwards i must
always know, wether the system call succeeded, or not.
i find no way of doing it. this is why i said "the whole system is
shi....." i am sorry about this sentence, but i was in a very bad mood,
because for weeks i try to solve this thing and i do not succeed.
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
Reply to: