Date: Sat, 14 Sep 2019 04:57:39 +0000 From: bugzilla-noreply@freebsd.org To: gnome@FreeBSD.org Subject: [Bug 236815] [patch] devel/glib20: loops over all possible file descriptors Message-ID: <bug-236815-6497-jypkTsihcx@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-236815-6497@https.bugs.freebsd.org/bugzilla/> References: <bug-236815-6497@https.bugs.freebsd.org/bugzilla/>
next in thread | previous in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D236815 --- Comment #23 from Ting-Wei Lan <lantw44@gmail.com> --- (In reply to Ting-Wei Lan from comment #12) > 1. malloc() can not cause deadlock, it is heavy used by many multithread = apps. Thread-safe does not imply async-signal-safe. The former can be achieved by using a mutex on shared resources, but the latter cannot. 'man fork' says: If the process has more than one thread, locks and other resources held by = the other threads are not released and therefore only async-signal-safe functio= ns (see sigaction(2)) are guaranteed to work in the child process until a call= to execve(2) or a similar function. Since fdwalk is called from the child process and it is possible for the pa= rent process to have multiple threads, it can only call async-signal-safe functi= ons. malloc is thread-safe but not async-signal-safe because the implementation= is likely to use a lock to protect global data. Assume that there is a thread calling malloc while you are calling fork. If the malloc lock is held while forking, the child process will have the malloc lock held as well. Since the child process only has one thread, which is the thread calling fork, the ma= lloc lock can never be released because the thread holding the lock does not exi= st in the child process. Therefore, if you call malloc in the child process be= fore exec, it is possible to cause deadlock. > 2. Docs says that opendir() is thread and mt safe: > http://man7.org/linux/man-pages/man3/opendir.3.html > But readdir() is not: MT-Unsafe: > http://man7.org/linux/man-pages/man3/readdir.3.html The current master branch uses neither opendir nor readdir. > 3. Reading dir using more than one syscall is bad idea because between re= ad > it can change some content is it will not be handled/processed. > As I remember this was a reason to drop opendir() in mine FAM backend and= =20 > some strange crashes: > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D214338 > So I do not understand why some one can need LOCK() in fdwalk(). fdwalk should not use LOCK. Where did you find it? --=20 You are receiving this mail because: You are the assignee for the bug.=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-236815-6497-jypkTsihcx>