On 09/18/2014 02:50 AM, Peng Haitao wrote: > On 09/15/2014 05:32 PM, Marko Myllynen wrote: >> Hi Michael, Haitao, >> >> iconv(3) states: >> >> ATTRIBUTES >> Multithreading (see pthreads(7)) >> The iconv() function is thread-safe. >> >> But iconv_open(3) says: >> >> A conversion descriptor contains a conversion state. After creation >> using iconv_open(), the state is in the initial state. Using iconv(3) >> modifies the descriptor's conversion state. (This implies that a con- >> version descriptor can not be used in multiple threads simultaneously.) >> To bring the state back to the initial state, use iconv(3) with NULL as >> inbuf argument. >> >> This looks a bit unclear, do you think you could clarify iconv(3) and/or >> iconv_open(3) a bit in thread-safety regard? It is conditionally thread safe :-) >> > > Yes, I will clarify it. > > When calling iconv() as iconv(cd, inbuf, ...) and iconv(cd, NULL, ...) > in multiple threads simultaneously, Segmentation fault may occur. > > So, I think the glibc's level "MT-Safe race:cd" is good. > http://www.gnu.org/software/libc/manual/html_mono/libc.html#index-iconv-1 The `cd' object is opaque to the user, and therefore in the glibc manual Alex and I felt it was appropriate to call out that it *is* thread safe to call this function but that the `iconv_t`-type object `cd` has itself no locking and can be corrupted by multiple calls with the same object, hence `race:cd` e.g. there is a data-race calling this function with the same cd object. Alex, please correct me if I'm wrong, but I think that sums it up. Cheers, Carlos. -- To unsubscribe from this list: send the line "unsubscribe linux-man" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
