Changes between Initial Version and Version 1 of Ticket #366, comment 6


Ignore:
Timestamp:
Aug 25, 2017, 8:33:06 PM (7 years ago)
Author:
dmik

Legend:

Unmodified
Added
Removed
Modified

  • Ticket #366, comment 6

    initial v1  
    1 Attached a patch that solves this problem by letting the callback be called last with a new !__LIBC_FORK_CTX_FLAGS_LAST flag. This serves well for LIBCx needs meaning that I can finally perform post-fork tasks in the child having LIBC itself fully operational (its Heap not locked, all properly handles inherited, etc.) now. This may be useful for other DLLs wanting to support forking too, of course.
     1Attached a patch that solves this problem by letting the callback be called last with a new !__LIBC_FORK_CTX_FLAGS_LAST flag. This serves well for LIBCx needs meaning that I can finally perform post-fork tasks in the child having LIBC itself fully operational (its Heap not locked, all file handles are properly inherited, etc.) now. This may be useful for other DLLs wanting to support forking too, of course.
    22
    33The only disadvantage is that it's impossible to fail gracefully from the forked child if something goes wrong because the completion callback is called when the communication between the parent and the child is mostly over. It would be better to have a fully functioning LIBC at a !__LIBC_FORK_OP_FORK_PARENT / !__LIBC_FORK_OP_FORK_CHILD time but given that LIBC finalizes itself from the completion callback as well, this would require to either change the way how LIBC uses callbacks for its own needs or call completion callbacks also per-module (rather than keep them in a global list processed at once in the end, after all per-module callbacks, like now). But both approaches seem non-trivial to implement so given that we may fail in the child by simply doing `exit(1)` or such inside the completion callback (which will result in EINTR from `fork()` on the parent side and LIBC PANIC bitching in the child), my patch seems fine.