* Suren Baghdasaryan: > Sending SIGKILL is blocking in terms of delivering the signal, but it > does not block waiting for SIGKILL to be processed by the signal > recipient and memory to be released. When I was talking about > "blocking", I meant that current kill() and friends do not block to > wait for SIGKILL to be processed. > process_reap() will block until the memory is released. Whether the > userspace caller is using it right after sending a SIGKILL to reclaim > the memory synchronously or spawns a separate thread to reclaim memory > asynchronously is up to the user. Both patterns are supported. I see, this makes sense. Considering that the pidfd sticks around after process_reap returns, the issue described in bug 154011 probably does not apply to process_reap. (This relates to asynchronous resource deallocation, as discussed before.) Thanks, Florian
