GsHostProcess child socket read: and readWillNotBlock behavior changes
In earlier versions, there was a file descriptor leak in GsHostProcess, bug 46730.
This bug has been fixed in v3.7.2, which results in an apparent behavior change in GsSocket >> readWillNotBlock.
The "leaked" file descriptor was the Gem process's writing end of the stdout and stderr pipes, and the read end of the stdin pipe. After the child was forked, the Gem previously failed to close its stdout/sterr write file descriptor, and this socket is inherited by the child. When the child process exited, it closed its own write file descriptor, but the Gem's was still open (although there was no way for data to appear on this socket).
As a result, in previous releases GsSocket >> read:* operations from the Gem to the child process, after the child process had exited, hung waiting for data to appear on the still-open socket.
With the fix for #47630, GsSocket >> read:* operations from the Gem to the child process after the child process had exited now correctly see the EOF and return 0, rather than hanging.
However, GsSocket >> readWillNotBlock also now (correctly) returns true in the case when the child has exited. Since the read:* operation on this socket will return an EOF without blocking, this is intended behavior, although it was not visible in earlier releases since the socket was not actually closed.
If existing code does not also check for read:* returning 0, and only checks the result of readWillNotBlock, then it may fail to recognize when the child has exited. Applications that are upgrading should check their application code to ensure the correct loop checks are done when communicating with the child process in GsHostProcess.
Workaround
In general, readWillNotBlock is not a reliable way to detect child status, although it is useful to avoid a read:* call waiting indefinitely for data to appear. For instance, there can be a false answer if the child process has not started writing or if it pauses in its writing.
Provided that your code can handle the GsProcess blocking until the child process has sent some data or closed its end of the pipe, there is no need to invoke readWillNotBlock.
Last updated: 12/30/24