[ruby-core:88071] [Ruby trunk Feature#5446] at_fork callback API

Issue #5446 has been updated by jeremyevans0 (Jeremy Evans).


normalperson (Eric Wong) wrote:
>  Maybe Sequel and AR can have add optional PID checks
>  ($$ != expected_pid), which is totally generic and usable
>  in bunch of cases.

My problem with doing this by default is that it penalizes knowledgeable users just to avoid problems for users that don't read the documentation.  Some libraries may consider that an acceptable tradeoff, but I do not.  I guess it depends at least partly on the expected audience for the library.

I'd be OK with this as an optional behavior, but in general anyone who would use it would be better off just disconnecting before forking, so I haven't implemented it yet.

>  AFAIK, Sequel and AR already provides out-of-the-box thread-safe
>  behavior.  Perhaps Sequel and AR should also have out-of-the-box
>  thread-AND-fork-safe connection pool which checks the PID.  I
>  don't expect PID check cost to be expensive, but they can make
>  that an option for users and it'll work on all forking servers
>  and maybe Guild servers in the future.

I'm guessing that Guild servers will operate differently than forking servers (not having different PIDs for different Guilds), but ko1 would know more about that.

>  I don't think limiting this to fork is necessary; forking may
>  become obsolete with Guilds.

I do not think that will be the case.  For one thing, you are always going to want a forking approach if you want a parent process that forks children and reaps them when they crash/exit.  This is especially true when the child process uses different permissions than the parent via `setuid`.  It could definitely be the case that a single-process multi-Guild approach will become more popular than current forking multi-process servers.

----------------------------------------
Feature #5446: at_fork callback API
https://bugs.ruby-lang.org/issues/5446#change-73091

* Author: normalperson (Eric Wong)
* Status: Assigned
* Priority: Normal
* Assignee: kosaki (Motohiro KOSAKI)
* Target version: 
----------------------------------------
It would be good if Ruby provides an API for registering fork() handlers.

This allows libraries to automatically and agnostically reinitialize resources
such as open IO objects in child processes whenever fork() is called by a user
application.  Use of this API by library authors will reduce false/improper
sharing of objects across processes when interacting with other
libraries/applications that may fork.

This Ruby API should function similarly to pthread_atfork() which allows
(at least) three different callbacks to be registered:

1) prepare - called before fork() in the original process
2) parent - called after fork() in the original process
3) child - called after fork() in the child process

It should be possible to register multiple callbacks for each action
(like at_exit and pthread_atfork(3)).

These callbacks should be called whenever fork() is used:

- Kernel#fork
- IO.popen
- ``
- Kernel#system

... And any other APIs I've forgotten about

I also want to consider handlers that only need to be called for plain
fork() use (without immediate exec() afterwards, like with `` and system()).

Ruby already has the internal support for most of this this to manage mutexes,
Thread structures, and RNG seed.  Currently, no external API is exposed.  I can
prepare a patch if an API is decided upon.




-- 
https://bugs.ruby-lang.org/

Unsubscribe: <mailto:[e-mail]?subject=unsubscribe>
<http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-core>