2

Some libraries might register some handlers with pthread_atfork(). I don't need them as I only use fork() together with exec(). Also, they can cause trouble in some cases. So, is there a way to reset the registered handler list?

Related: calling fork() without the atfork handlers, fork() async signal safety.

Albert
  • 65,406
  • 61
  • 242
  • 386
  • The primary documented operational issue with `atfork` handlers involves the case in which `fork()` is called by a signal handler, and thus the `atfork` handlers are called in the signal handler's context. Is this an issue you actually need to worry about? – John Bollinger Oct 18 '17 at 14:21

1 Answers1

1

POSIX does not document any mechanism for fork handlers installed by pthread_atfork() to be removed, short of termination of the process or replacing the process image. If you don't want them, then don't install them. If they are installed by a third-party library, as you describe, then your options are to find a way to avoid that behavior of the library (possibly by avoiding the library altogether) or to live with it.

John Bollinger
  • 160,171
  • 8
  • 81
  • 157
  • You'll have to help me out there, @Albert. Where did you read about that? As far as I can determine, no such identifier is specified by POSIX for any entity whatever. It looks like GLIBC may have an internal function with a name similar to that, but if so, it is not intended to be called directly, and it is not portable. – John Bollinger Oct 18 '17 at 15:56
  • In the [Glibc `fork.h`](https://sourceware.org/git/?p=glibc.git;a=blob;f=sysdeps/generic/fork.h;h=623cae28dfa22d00ed09b8842ca36f44f733942c;hb=HEAD), it says UNREGISTER_ATFORK, If defined it must expand to a function call which takes one void* parameter which is the DSO handle for the DSO which gets unloaded. The function so called has to remove the atfork handlers registered by this module. I saw that some C++ stdlib implementations use this. – Albert Oct 18 '17 at 16:03
  • @Albert, (1) that's GLIBC-specific. (2) It is a macro, not a function, used internally in GLIBC's implementation. Defining it in your own code will have no effect on the already-compiled GLIBC code that uses it. (3) It anyway does not address your problem. It allows GLIBC's component libraries to designate a function to call to remove their own atfork hooks, but what you asked for is a way to *implement* such a function. – John Bollinger Oct 18 '17 at 16:34
  • I don't want to change already-compiled Glibc code. I just want to reset the handlers. And I think this symbol is exported. So if I know the DSO of all the libs, I can reset their handlers. Of course this covers only Glibc, but at least it partially does what I want, right? – Albert Oct 18 '17 at 17:14
  • No, @Albert, the `UNREGISTER_ATFORK` symbol is *not* exported. As it is used by GLIBC, it must be defined -- I repeat -- as a macro, not a function. Macros are expanded at compile time (*glibc* compile time, in this case); their identifiers do not become external symbols. You are looking at an internal extension point in GLIBC, not an external interface. – John Bollinger Oct 18 '17 at 18:09
  • @Albert, supposing that you are using a DSO version of your library, and supposing further that it provides an unregistration-handling function with external linkage, yes, you could call that function. Even if you can discover such a function, however, you cannot be certain that it is safe to call it outside the scope of unloading the DSO. You also have no guarantee about the stability or continued existence of such a function across platforms or versions of the library. Until and unless it is documented, it is an implementation detail. – John Bollinger Oct 18 '17 at 18:17