From: Valentin Bonnard (Bonnard.V_at_[hidden])
Date: 2000-09-02 20:39:26
On Sat, Sep 02, 2000 at 08:57:15AM +0100, Kevlin Henney wrote:
> In message <20000902013848.04281_at_[hidden]>, Valentin Bonnard
> <Bonnard.V_at_[hidden]> writes
> >On Fri, Sep 01, 2000 at 09:39:34AM +0100, Kevlin Henney wrote:
> >> And the only things they do "promise" are related to signals, not to
> >> threading.
> >That's the same thing !
> I assure you, it is not.
So explain me why. I really don't see the difference.
> >> Introducing a dependency on <csignal> would be misleading
> >> (threads and signals interact _badly_) and incorrect :-}
> >(signals interact badly with almost everything)
> But particularly with threads. A number of years ago, whilst POSIX.4a
> was in draft (around draft 10 I think), I was working on a system that
> used pthreads. The interaction between threads and signals was poorly
> specified and one of the more volatile elements of the standard.
> >Why do you think that a shared unprotected (ie w/o locks) variable
> >of type volatile sig_atomic_t can't be used for inter-thread
> >communication ?
> Because the standard does not say they can. Simple really ;-)
So there are no specific reasons ?
> >(BTW, I haven't been able to find specific guaranties about
> >sig_atomic_t in the C++ standard; are they hidden in the C
> >standard ? In particular, is sig_atomic_t()++ guarantied
> >to be atomic ?)
> No such guarantee exists. Greg pretty much posted all the guarantees you
What Greg posted is the dual of guaranty: if you don't do that
they are no guaranties. Does it count as a guaranty (if you do
that, there are guaranties) ? Or is a signal handler expected
to behave like any other C++ function, except for specific
exceptions (types other than volatile sig_atomic_t, etc.) ?
I tend to think that the correct interpretation is the latter,
but this is a strange way of writting specifications.
-- Valentin Bonnard
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk