bug in gmp_fprintf?

[Niels Möller]

tg at gmplib.org (Torbjörn Granlund) writes:

> I understand stdio locking poorly.

My understanding is that it has two purposes: (1) protect internal
consistency of the FILE struct, and (2) let threads read and write from
streams without getting the data mixed up randomly.

> I understand that if several threads read from the same stream, some
> sort of synchronisation will be required for things to stay sane.

And getc does that locking and unlocking for each char read, which makes
it not at all as fast as it was intended to be. While getc_unlocked does
exactly what getc used to do, before multithreading support was added to
libc.

> If we're to lock the input stream here, it could stay locked for
> minutes.  That might perhaps be bad.

I donät think it's too bad. If some other thread attempts to read from
the file, it has to wait until gmp_fscanf is finished. Which I think is
saner, than if the other threads gets to steal some of the input digits.

Locking an output stream for a long time might be more of a problem.
Question is, what's worse, letting the writer wait, or getting its
output inserted in the middle of a GB of digits output by gmp_fprintf?

I think it's unlikely in practice to have multiple threads accessing a
stream at the same time, with the exception of output to stderr or other
logging abstractions.

Regards,
/Niels

-- 
Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26.
Internet email is subject to wholesale government surveillance.