On Sat, Dec 28, 2013 at 2:03 PM, <[email protected]> wrote: > > Comment #2 on issue 255 by [email protected]: Forking threads > fails with clang 3.4 > http://code.google.com/p/address-sanitizer/issues/detail?id=255 > > Mixing fork and threads is clearly tricky, this is not forbidden and have > some working use cases (in my case, snapshotting the state of a database)... > you mostly have to make sure that the forked thread don't use mutexes from > the parent process. > > I'll find a workaround of my own, but I really think this is a regression > from ASan since it worked perfectly from day 1 and only broke when using > clang 3.4.
Yes, strictly saying it is legal. POSIX says: "A process shall be created with a single thread. If a multi-threaded process calls fork(), the new process shall contain a replica of the calling thread and its entire address space, possibly including the states of mutexes and other resources. Consequently, to avoid errors, the child process may only execute async-signal-safe operations until such time as one of the exec functions is called. [THR] Fork handlers may be established by means of thepthread_atfork() function in order to maintain application invariants across fork() calls." http://pubs.opengroup.org/onlinepubs/009695399/functions/fork.html It's not even required to execute only async-signal safe functions. If you are careful to establish invariants, you can use any functions. -- You received this message because you are subscribed to the Google Groups "address-sanitizer" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/groups/opt_out.
