------- 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
