[Bug libstdc++/21334] Lack of Posix compliant thread safety in std::basic_string

["jkanze at cheuvreux dot com" <gcc-bugzilla at gcc dot gnu dot org>]

------- Additional Comments From jkanze at cheuvreux dot com  2005-05-03 09:09 -------
Subject: Re:  Lack of Posix compliant thread safety in std::basic_string


|> Whereas I'm all for providing alternate memory management
|> policies (we are very close to that in the v7-branch and I
|> promise further progress during the next months) I fail to
|> properly appreciate the actual details of this issue: which
|> applications are actually penalized, which are the alternatives,
|> something more concrete, in other terms, that a vague reference
|> to those "position" papers that we all know, in other terms ;)
|> (and one of those I'd like to discuss in detail...) Maybe James
|> can help here.

I'm not sure what sort of help you are looking for.  I thought
that I very clearly pointed out the problem, and the point in
the code where it occured.

In typicaly code, the problem occurs mainly with configuration
variables; they are declared non-const, because they have to be
set on start up, either from the command line, or from a
configuration file, and then used as if they were const.
According to Posix, I should be able to access such variables
without additional, user defined synchronization.

Note that the problem can be very, very subtle, and that most of
the time, the program will work despite the problem -- this is
one of the most pernicious cases of undefined behavior.

|> In practice, we could, for instance, *within the
|> current ABI*, provide a switch to disable completely reference
|> counting, would that be appreciated?

It would help.  But an implementation designed with reference
counting in mind is likely to be rather slow when reference
counting is turned off.  IMHO, correct and slow is better than
the current situation, but not all compiler users agree.

|> I can implement this very
|> quickly but I'd like to have some evidence that a non-trivial
|> number of users would appreciate that short-term solution.  That
|> would be indeed, a short term solution, because a library
|> relying purely on a non-refcounted string has subtle issues with
|> memory allocation during exceptions, that definitely we don't
|> want in a long term solution: if nobody has got a better idea,
|> I'm afraid we have to implement also a separate ref-counted
|> mini-string for usage in exceptions.

Most other implementations I'm aware of don't use std::string in
exceptions.  That would seem to be the best solution.

Other than that, there is no perfect solution with regards to
exceptions.  If an exception requires resources, and they aren't
there, there's going to be a problem.  What happens if you can't
allocate the memory for the exception itself?

--
James Kanze

"This message, including any attachments may contain confidential and
privileged material; it is intended only for the person to whom it is
addressed. Its contents do not constitute a commitment by Credit Agricole
Cheuvreux except where provided for in a written agreement. Credit Agricole
Cheuvreux assumes no liability or responsibility for the consequences
arising out of a delay and/or loss in transit of this message, or for
corruption or other error(s) arising in its transmission and for any misuse
or fraudulent use which may be made thereof. If you are not the intended
recipient, please contact us and abstain from any disclosure, use or
dissemination. To the extent that this message contains research
information and/or recommendations, these are provided on the same basis as
Credit Agricole Cheuvreux's published research and the recipient must have
regard to all disclosures and disclaimers contained therein."






-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21334