Pb : signals

[Giuseppe]

hello,

I have a small question, how to prevent EINTR error. I use semaphore to
access shared memmory, i also use a signal function to catch SIGINT....
and when i send a signal to a process sometimes i get "interrupted system
call".

........
........
sigemptyset(&set);
sigaddset(&set, SIGINT);
sigaddset(&set, SIGUSR2);
sigaddset(&set, SIGTSTP);
loop
.......
.......
sigprocmask(SIG_SETMASK, set, NULL);
semP(); // my semaphore functions
.....
.......

semV();
sigprocmask(SIG_UNBLOCK, set, NULL);

I read that signals which are blocked are not dropped, so in my opinion
this code should be working. Thanks for any help

 

[Antoninus Twink]

This isn't a question about C; try comp.unix.programmer.

As you are well aware Eric, this is complete nonsense. Signals are part
and parcel of the C Standard - there is even a Standard C function
called signal()!

To the OP: many function calls can be interrupted by a signal and return
EINTR; almost always, you'll want to restart the function call. A common
idiom is:

do
retval = some_function(fd, &buf, len);
while(retval == -1 && errno == EINTR);

and often people write little wrapper functions to do this automatically
for common I/O functions etc. that they use a lot.

 

[Nobody]

I have a small question, how to prevent EINTR error.

In general, you need to handle it rather than trying to prevent it. If
you are using any external libraries, you may not be able to ensure that
every signal handler is installed with the SA_RESTART flag.

Also, which system calls are restartable is platform-specific.

I use semaphore to
access shared memmory, i also use a signal function to catch SIGINT....
and when i send a signal to a process sometimes i get "interrupted system
call".

In which function? Some (but not all) blocking system calls are
restarted if the handler was installed with the SA_RESTART flag.

In particular sem_wait() and sem_timedwait() are restartable in Linux
2.6.22 and later; in earlier kernels, they fail with EINTR.

I read that signals which are blocked are not dropped, so in my opinion
this code should be working. Thanks for any help

If your code is multi-threaded, the behaviour of sigprocmask() is
undefined; use pthread_sigmask() instead.

 

[Nobody]

As you are well aware Eric, this is complete nonsense. Signals are part
and parcel of the C Standard - there is even a Standard C function
called signal()!

EINTR isn't in ANSI C. The only errno values specified by the standard are
EDOM, EILSEQ and ERANGE.

 

[Phil Carmody]

EINTR isn't in ANSI C.

It's addressed by ANSI C - it's UB!

Phil

 

[Nick Keighley]

more accurately: this ng is devoted to standard C (ISO or K&R) and
you
are asking about Unix specific extensions. The people on a Unix group
are likely to be more knowledgeable so you are better off asking your
questions there.

but he was asking about stuff that well beyond the standard.
To the OP: Twink is a troll that likes to disrupt the ng.
Check the archives (if they are working :-( ) for his history.

It's addressed by ANSI C - it's UB!

where?

 

[Loïc Domaigné]

As you are well aware Eric, this is complete nonsense. Signals are part
and parcel of the C Standard - there is even a Standard C function
called signal()!

I second Eric. sigemptyset(), sigaddset(), sigprocmask() and what the
OP is asking for is UNIX specific, and not related to ANSI C.

Of course, it doesn't contradict that some comp.lang.c addicted
posters can answer the question

Cheers,
Loïc

 

[Antoninus Twink]

this ng is devoted to standard C (ISO or K&R)

You may wish that was so Nick, but the clue is in the name: comp.lang.c.
This newsgroup deals with *all* C questions, not just ISO C.

 

[Kenny McCormack]

You may wish that was so Nick, but the clue is in the name: comp.lang.c.
This newsgroup deals with *all* C questions, not just ISO C.

Only lunatics maintain that C code that includes extensions beyond the
"standard" is not C code.

Fortunately (or unfortunately, depending on your point of view), we have
no shortage of lunatics in this newsgroup.

P.S. It seems abundantly clear to me that an X with Y is still an X.
But others don't see it that way. Funny, that...

 

[Barry Schwarz]

It's addressed by ANSI C - it's UB!

7.5-4 authorizes implementations to define additional macros for errno
values. EINTR matches the format for such a macro.

7.14.1.1-8 states that some positive but unspecified number is stored
in errno under certain conditions. While the value could match one of
the standard macros, it would be a perverse implementation that did
so.