On 11/24/2013 01:13 AM, Pádraig Brady wrote: > While looking at the recent possible gettext() multithreaded issue, > I also noticed that there were references to *_unlocked functions > in the sort command, which doesn't look right.
Actually on further inspection the fread() is done from a single thread. Also the fwrite()s can happen from separate threads, even to the same FILE*, but there is higher level locking in place as the order of writes is quite important to sort(1) :) > So the remaining must be coming from gnulib: > > $ (cd ~/git/gnulib/lib/ && grep unlocked-io.h *) > argmatch.c:# include "unlocked-io.h" > close-stream.c:# include "unlocked-io.h" > error.c:# include "unlocked-io.h" > exclude.c:# include "unlocked-io.h" > getdelim.c:# include "unlocked-io.h" > getndelim2.c:# include "unlocked-io.h" > getpass.c:# include "unlocked-io.h" > getusershell.c:# include "unlocked-io.h" > linebuffer.c:# include "unlocked-io.h" > md2.c:# include "unlocked-io.h" > md4.c:# include "unlocked-io.h" > md5.c:# include "unlocked-io.h" > mountlist.c:# include "unlocked-io.h" > posixtm.c:# include "unlocked-io.h" > readtokens.c:# include "unlocked-io.h" > readutmp.c:# include "unlocked-io.h" > sha1.c:# include "unlocked-io.h" > sha256.c:# include "unlocked-io.h" > sha512.c:# include "unlocked-io.h" > version-etc.c:# include "unlocked-io.h" > But I'd probably remove unlocked-io.h use from > a few more of the top gnulib module list while at it? So while some of the above mightn't need the unlocked variants for performance, using unlocked IO does give a multithreaded program more control through flockfile() over grouping separate stdio calls to a particular descriptor. But... > I wonder should we add a warning if USE_UNLOCKED_IO is 1 > while any of the gnulib threading modules are included? ... using unlocked I/O in multithreaded programs does require some form of locking and so a gnulib warning stating that would probably be appropriate. I'll look at adding that later. thanks, Pádraig.
