Skip to content
Snippets Groups Projects
Select Git revision
  • master default protected
  • 9.0
  • 8.0
  • 7.8
  • 7.6
  • 7.4
  • 7.2
  • 7.0
  • 0.6
  • rosuav/latex-markdown-renderer
  • rxnpatch/rxnpatch
  • marcus/gobject-introspection
  • rxnpatch/8.0
  • rosuav/pre-listening-ports
  • nt-tools
  • rosuav/async-annotations
  • rosuav/pgsql-ssl
  • rxnpatch/rxnpatch-broken/2023-10-06T094250
  • grubba/fdlib
  • grubba/wip/sakura/8.0
  • v8.0.1994
  • v8.0.1992
  • v8.0.1990
  • v8.0.1988
  • v8.0.1986
  • rxnpatch/clusters/8.0/2025-04-29T124414
  • rxnpatch/2025-04-29T124414
  • v8.0.1984
  • v8.0.1982
  • v8.0.1980
  • v8.0.1978
  • v8.0.1976
  • v8.0.1974
  • v8.0.1972
  • v8.0.1970
  • v8.0.1968
  • v8.0.1966
  • v8.0.1964
  • v8.0.1962
  • v8.0.1960
40 results

backend.cmod

Blame
    • Marcus Cromnow's avatar
      4b76fd4c
      Delay setup of backend wakeup pipe. · 4b76fd4c
      Marcus Cromnow authored
      This delays the wakeup pipe until after the backend is actually used.
      
      The main reason is that after fork() all copies of the process always
      have the same wakeup pipe.
      
      Waiting until the first use of the backend makes wake_up_backend()
      useful again in forked processes (as long as the backend has not been
      used before the fork).
      
      Fixes a bug in turboproxy, we use a master backend system where all
      modules are loaded and partially initializes in a 'master' backend,
      and new backends are then forked of from the master as needed.
      4b76fd4c
      History
      Delay setup of backend wakeup pipe.
      Marcus Cromnow authored
      This delays the wakeup pipe until after the backend is actually used.
      
      The main reason is that after fork() all copies of the process always
      have the same wakeup pipe.
      
      Waiting until the first use of the backend makes wake_up_backend()
      useful again in forked processes (as long as the backend has not been
      used before the fork).
      
      Fixes a bug in turboproxy, we use a master backend system where all
      modules are loaded and partially initializes in a 'master' backend,
      and new backends are then forked of from the master as needed.