Re: new module for temporary files in temporary directories

[Ben Pfaff]

Paul Eggert <address@hidden> writes:

> Ben Pfaff <address@hidden> writes:
>
>> The issue at hand, as I understand it, is not even the general
>> behavior of signals.  It is the behavior of fatal signals.  That
>> is, a the program terminates without ever returning from the
>> signal handler.  This is much simpler than the general problem
>
> Yes, good point; it is simpler.  However, my impression is that the
> new module's cleanup function is intended to be callable even from
> non-fatal signal handlers, so I don't think we have the simpler case
> here.  But for now let's concentrate on the simpler case.

Is this a feature that Bruno will add later?  I don't see a way
to do it at the moment.

>> However, I believe that if the assignment in main were changed to
>> the following, then the signal handler would be guaranteed to see
>> 1 in x if the signal arrived in getchar;
>>         *(sig_atomic_t volatile *) &x = 1;
>
> OK, so it sounds like your idea is that, if all accesses to an object
> are via a volatile lvalue, then the object is volatile, even if it was
> not originally defined to be a volatile object.  This idea has an
> intuitive appeal, though I submit that it does not follow from the
> standard; the standard does not explicitly specify or even suggest
> this "all accesses" rule.

I think I'm still not doing a good job of explanation.  My theory
is that any object may be accessed through a volatile lvalue and
receive volatile semantics *for that access* (rationale 6.7.3,
last paragraph).  An object *defined as* volatile must always be
accessed through a volatile lvalue (6.7.3p5).  But an object
*not* defined as volatile *may* be accessed through a volatile
lvalue (6.7.3p7).  That doesn't make the object volatile and it
doesn't mean that you always have to access the object via
volatile semantics.

> A problem I see with this idea is 6.7.3.(6), which says "An object
> that has volatile-qualified type may be modified in ways unknown to
> the implementation or have other unknown side effects."  So a volatile
> object (I assume this is the same as "an object that has
> volatile-qualified type" in your model?) can spontaneously change, for
> reasons unknown to and outside the control of the program; this point
> is underlined later in the paragraph.  But if all accesses to a
> humdrum "static int x;" object are via volatile lvalues, and if that
> means "x" is a volatile object, doesn't this also mean "x" might
> spontaneously change?

I have always "read between the lines" that this applies only to
volatile objects that actually refer to unusual things that are
not normal memory (e.g. MMIO, as you say), probably involving
linker scripting or pointer casts to assign them to magical
addresses.  It has never occurred to me that it applies to every
volatile object.  For example, consider the use of "volatile" in
conjunction with "longjmp", to guarantee that automatic variables
have unsurprising values after the jump.  It would be *very*
surprising if these values spontaneously changed!

> One way out of this mess would be to say that we are making an extra
> assumption, not present in the standard, that volatile objects do not
> spontaneously change and that they have no unknown side effects.  To
> some extent we must make this assumption anyway, or we'll get nowhere.
> Still, 6.7.3.(6) makes it clear (at least to me) that "volatile" is
> intended more for describing access to memory-mapped device registers,
> and wasn't really intended for use in safe signal handling or
> multithreading.

Yes.

> There is also the huge escape clause at the end of 6.7.3.(6): "What
> constitutes an access to an object that has volatile-qualified type is
> implementation-defined."  Ouch!  Talk about getting run over by an
> express train!

No kidding.

> Anyway, to get back to the original module, it seems to me that the
> code actually is assuming something quite a bit different from what
> 'volatile' provides.  The code is attempting to do use loads and
> stores as barriers to prevent the usual sorts of bugs with signal
> handling.  But 'volatile' is not designed to handle this problem:
> volatile accesses are not guaranteed to be atomic.

It'd be *much* better if we had a way to do atomic
accesses--please don't take my arguments as being *in favor of*
volatile.  Almost any other solution would be preferable.  It's
too bad that all the other solutions are even less portable (as
far as I know).

-- 
"Ho ho ho. I _so_ enjoy making a fool out of myself."
--Linus, on Christmas Day, 2000