Make mblen, mbtowc, and wctomb thread-safe for encodings that are not state-dependent.
CR 498 has been resolved by stating that mblen, mbtowc, and wctomb are not thread safe, even when the encoding is not state-dependent.
However, there would be advantages to making them thread-safe for encodings that are not state-dependent. Such a change should be considered for the future C standard.
For encodings that are not state-dependent, mblen, mbtowc, and wctomb can easily be implemented without using any internal state. Making this a requirement would allow multithreaded applications to use these functions (as long as it is known that the encoding is not state-dependent, which is true for nearly all encodings and can be queried using existing functionality).
Currently, multithreaded application have to use synchronization or use the restartable mbrlen(), etc instead. Neither is a good option where speed or code size matters.
Synchronization obviously has quite some overhead, and unnecessary synchronization should be avoided for multithreaded programs.
The restartable functions are slow and big (being restartable they need to be able to handle incomplete input). This can be seen in CR 498, and was stated by multiple attendants of the London meeting.
§7.22.7 from (text from CR 498 resolution)
Changing the LC_CTYPE category causes the conversion state of these functions to be indeterminate. A call to any one of these functions may introduce a data race with a call to any other function in this subclause.
to
Changing the LC_CTYPE category causes the conversion state of these functions to be indeterminate. For state-dependent encodings only, a call to any one of these functions may introduce a data race with a call to any other function in this subclause.