Niklas Matthies <news_comp.std.c++_expires-2001-09-01@nmhq.net> wrote:
: On Mon, 25 Jun 2001 17:34:59 GMT, Kiril Avdeiv <kavdeiv@mail.ru> wrote:
:> I've been going through the C++ standard and C90 the other day and
:> realized that they both fully define and support the UNIX notion of a
:> signal. C++ clearly states that a signal handler must be a POF, and
:> they even introduce the type sig_atomic_t, such that a volitile object
:> of such type can be predictably accessed and modified from a signal
:> handler (even for an asynchronous interrupt). C90 even touches on such
:> finer details of signal handling as to explain that on program start
:> up all the handlers are set to their defaults or are ignored, which
:> goes hand in hand with the UNIX fork/exec semantics.

: I think you are missing the fact that practically all useful things that
: you'd want do with signals result in undefined behavior in C90. (And
: this has't changed much in C99.) You might want to look up the threads
: on comp.std.c where this has been discussed a couple of times.

Just to amplify on that a bit, in C90 a signal handler cannot read a
static variable without invoking undefined behavior.  Essentially, all
that a conforming signal handler can do is to set a flag of type
volatile sigatomic_t.  In fact, SIGFPE can't even return without
invoking undefined behavior.  (Instead, he has to longjmp back.)

It my impression the standards can do a lot better than they've done.
A lot of people reply, "That's what POSIX is for, so why bother."  It
seems to me that too much other stuff comes along with POSIX, however.
But even if we had a more useful standard for signals, we'd need yet
another standard for multi-threading.

Tom Payne

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]

I've been going through the C++ standard and C90 the other day and realized that they both fully define and support the UNIX notion of a signal. C++ clearly states that a signal handler must be a POF, and they even introduce the type sig_atomic_t, such that a volitile object of such type can be predictably accessed and modified from a signal handler (even for an asynchronous interrupt). C90 even touches on such finer details of signal handling as to explain that on program start up all the handlers are set to their defaults or are ignored, which goes hand in hand with the UNIX fork/exec semantics.

All that is fine and I'm all for it and value it. The question that came to my mind is the following. I many times read interviews with Bjarne Stroustrup and many other prominent C++ figures and when he was asked about the lack of support for multithreading he replied that such things are very much implementation and platform dependent and belong to a library.

But look, signals are also platform and implementation dependent. There are no native signals on WIN32, for example. Why does the simantics of signal handling so closely resemble those employed in unix programming, especially those that match fork/exec functionality. This is a kind of hypocritical to say that a language should not define anything that is not common to all the major platforms, and yet fully define signals, which are very platform specific and are manly used on Unixes only.

By the way BS seems to've changed his mind recently and now urges people to come up with a good implementation of threads in his C++0x (even if some minor new changes to the core language are necessary).

I feel that this all is very hypocritical. Can some one enlighten me up on it?

Thank you
Kiril


--
Posted from 172.16.27.62, 172.16.17.153 via proxy [212.72.53.70] by way of mx6.port.ru [194.67.23.42]
via Mailgate.ORG Server - http://www.Mailgate.ORG

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]

> I feel that this all is very hypocritical. Can some one enlighten me up on it?

I think this is a bit of a split between the C standards people and the
C++ ones.  The C standard did pick up a bit of UNIX baggage with regard
to signals.  Really, they are NOT a portable concept and they don't
boogie well with C++ anyhow.  Short of C++ coming up with some portable
way of doing it right, they just inherit the incumbant C ugliness.

While I'm not sure multithreading issues and operating system interfaces
such as signal handling can ever be trully relegated to a "library,"  it
is pretty clear that they are an add-on to the language just as with the
rest of the OS support such as process handing and graphical interfaces
and best dealt with in a separate stndards effort.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]

On Mon, 25 Jun 2001 17:34:59 GMT, Kiril Avdeiv <kavdeiv@mail.ru> wrote:
> I've been going through the C++ standard and C90 the other day and
> realized that they both fully define and support the UNIX notion of a
> signal. C++ clearly states that a signal handler must be a POF, and
> they even introduce the type sig_atomic_t, such that a volitile object
> of such type can be predictably accessed and modified from a signal
> handler (even for an asynchronous interrupt). C90 even touches on such
> finer details of signal handling as to explain that on program start
> up all the handlers are set to their defaults or are ignored, which
> goes hand in hand with the UNIX fork/exec semantics.

I think you are missing the fact that practically all useful things that
you'd want do with signals result in undefined behavior in C90. (And
this has't changed much in C99.) You might want to look up the threads
on comp.std.c where this has been discussed a couple of times.

-- Niklas Matthies

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]