You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Commit e6acbe5
Browse filesBrowse the repository at this point in the historyBrowse files
With DPL_FORK_WITHOUT_EXEC=1 in the environment, the driver only forks
the data processors it defined itself, i.e. those not imported from an
upstream workflow, including the internal ones, and the child runs the device
straight away, from the topology, libraries and services the driver has
already set up. Data processors imported from an upstream workflow are
still exec'd, since only their executable can define them. By default
nothing changes: the exec path is as before, and the new code is only
reached when noExec is set.
The forked child is made to look like one which did exec:
- only the driver's end of the pipes of the devices forked so far, and
of its own, are closed, rather than every descriptor: what the driver
opened, e.g. libuv's signal lock pipe, recreated at fork, is still in
use in the child. The pipes of the next devices do not exist yet.
- SIGUSR1/SIGUSR2 are ignored as on the exec path, and the handlers the
driver installed for SIGINT, SIGTERM and SIGCHLD are reset, as exec
would do.
- it gets a loop of its own, the driver's listening socket is closed,
and it reads to the end the workflow the driver streams on its stdin,
so the driver neither blocks on nor gets SIGPIPE from that pipe.
- stdio is flushed before forking, so nothing is printed twice.
- on macOS its os_log handles are replaced by OS_LOG_DISABLED: after a
fork without exec os_signpost_enabled() reports every one of them as
enabled, so every signpost argument would be evaluated. --signposts
still works, since it does not go through os_log. This was seen as a
crash in test_SimpleWildcard: the data_relayer signpost in saveInSlot
dereferences a null input channel for the second wildcard route. That
is an upstream bug, the same crash happens in exec mode with
--signposts data_relayer.
- getIdString() returns the device id, so that the workflow termination
hook knows it runs in a device, as test_RootTreeWriterWorkflow needs.
- it only redoes the steps the driver did not perform before forking:
MERGE_CONFIGS, IMPORT_CURRENT_WORKFLOW and MATERIALISE_WORKFLOW (from
6903032bdeac).
0 commit comments