Paul Eggert wrote:
> Linus Torvalds has deprecated the use of 'volatile' in data
> structures for optimization barriers (which is the use that started
> this thread), and prefers the use of primitives like barrier()
> instead.
Sure, I agree that it's easier to write wrong code with 'volatile'
than
Bruno Haible <[EMAIL PROTECTED]> writes:
> The Intel compiler people also have the declared goal of supporting the
> Linux kernel. They spent a lot of effort adding support for __asm__ in gcc's
> semantics; I don't think they would drop this support for a different
> semantics of 'volatile'.
Sure
Paul Eggert wrote:
> > 'malloc' is one such function.
>
> My intuition is the oppposite; I would expect 'malloc' to have more
> problems than a random user function, since the compiler "knows" more
> of malloc's properties.
The compiler knows about it, but its code is quite complex, therefore hard
Bruno Haible <[EMAIL PROTECTED]> writes:
> In theory, yes. In practice, we can stop the propagation of 'volatile'
> at function boundaries, for functions we know the compiler will not
> inline. (Only if the compiler inlines a function, it has the chance to
> reorder the statements in ways that wer
Paul Eggert wrote on 2006-07-05:
> > The rule of thumb is: If a data field can be written by the main program
> > and read by the signal handler, or vice versa, it needs to be marked as
> > 'volatile'.
>
> OK, thanks for explaining it. Though I think you meant that the field
> needs to be accesse
Ben Pfaff <[EMAIL PROTECTED]> writes:
> Is this a feature that Bruno will add later?
I suspect so, if we want 'sort' to use the module (still haven't
decided that).
> My theory is that any object may be accessed through a volatile
> lvalue and receive volatile semantics *for that access* Tha
Paul Eggert <[EMAIL PROTECTED]> writes:
> Ben Pfaff <[EMAIL PROTECTED]> 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.
Ben Pfaff <[EMAIL PROTECTED]> 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
Paul Eggert <[EMAIL PROTECTED]> writes:
> Ben Pfaff <[EMAIL PROTECTED]> writes:
>
>> This is a particularly pessimistic interpretation of the
>> standard,
>
> You think _I'm_ pessimistic! You should hear Nick MacLaren and Dave
> Butenof. Here's a sample quote (in the threading area):
>
> ... t
Ben Pfaff <[EMAIL PROTECTED]> writes:
> This is a particularly pessimistic interpretation of the
> standard,
You think _I'm_ pessimistic! You should hear Nick MacLaren and Dave
Butenof. Here's a sample quote (in the threading area):
... the use of volatile accomplishes nothing but to prevent
Paul Eggert <[EMAIL PROTECTED]> writes:
> Bruno Haible <[EMAIL PROTECTED]> writes:
>
>> 3) The theoretical reason is that in ISO C, section 5.1.2.3.(5)
>> guarantees to me that memory stores have been performed at sequence points
>> only if I mark them 'volatile'.
>
> I think that's a misunderstan
Bruno Haible <[EMAIL PROTECTED]> writes:
> The rule of thumb is: If a data field can be written by the main program
> and read by the signal handler, or vice versa, it needs to be marked as
> 'volatile'.
OK, thanks for explaining it. Though I think you meant that the field
needs to be accessed o
Bruno Haible <[EMAIL PROTECTED]> writes:
> 1) The practical reason is that while developing libsigsegv, I noticed that
> C does not have the notion of a "barrier": In code like this:
>
> set_up_datastructures();
> /* HERE I would like a barrier */
> signal(sig,my_signal_handler);
Ben Pfaff wrote:
> > /* Create a temporary directory.
> >PREFIX is used as a prefix for the name of the temporary directory. It
> >should be short and still give an indication about the program.
> >Return a fresh 'struct temp_dir' on success. Upon error, an error
> > message
> >is
Paul Eggert wrote:
> > The module is, so far, not optimized for asymptotic performance.
> > How many temporary files does 'sort' use? Is more than 1 temp files
> > realistic (each of size > 10 MB, giving a total of 100 GB) ?
>
> Yes, I'm afraid it is. People are sorting larger files these day
Bruno Haible <[EMAIL PROTECTED]> writes:
> /* Create a temporary directory.
>PREFIX is used as a prefix for the name of the temporary directory. It
>should be short and still give an indication about the program.
>Return a fresh 'struct temp_dir' on success. Upon error, an error messa
Bruno Haible <[EMAIL PROTECTED]> writes:
> (Since the cleanup handler is registered before the file or subdir
> is created, it can happen that the cleanup handler is invoked at a
> moment when the file does not yet exist. This is normal.)
Yes, that's expected.
> The module is, so far, not optimi
Paul Eggert wrote:
> Some problems I noticed:
>
> * The GNU coding standards say that one shouldn't use "path" to
> describe a file name; "path" should be used for things like PATH
> instead, which are lists of file names. Several of the comments and
> names of functions etc should be chang
Bruno Haible <[EMAIL PROTECTED]> writes:
> I'd like to propose a module which supports temporary directories,
> and cleans them up either upon request or at a fatal signal.
This sounds like a good module to have. I like the idea of putting
all the temp files into a subdirectory.
Some problems I
Hi,
Programs which create several temporary files or want to prescribe
a given basename to the files can do so easily by using a temporary
directory, and the temporary files inside this temporary directory.
When implementing this approach, however, the bookkeeping needed for
proper cleanup of the
20 matches
Mail list logo
