Prior to this change, if wantWrite() was called from another thread while NuProcess was calling onStdinReady(ByteBuffer), that request would be "lost" if onStdinReady returned false. Depending on where input is coming from (for example a Servlet 3.1 ReadListener), that could result in the process getting "stuck" indefinitely.
Updated BasePosixProcess.writeStdin(int, int) to clear the userWantsWrite flag, if it's set, prior to calling onStdinReady, and then only re-set userWantsWrite if onStdinReady returns true
Updated WindowsProcess.writeStdin(int) to use the same technique
Also fixed an unrelated bug where checkHandleValidity was comparing the provided HANDLE to the invalid handle's pointer, rather than comparing pointers from both
Added a new unit test that verifies the wantWrite() request isn't "lost" if it happens during an onStdinReady callback
This test fails on Linux, macOS and Windows without the changes to writeStdin in BasePosixProcess and WindowsProcess
Prior to this change, if
wantWrite()
was called from another thread while NuProcess was callingonStdinReady(ByteBuffer)
, that request would be "lost" ifonStdinReady
returnedfalse
. Depending on where input is coming from (for example a Servlet 3.1ReadListener
), that could result in the process getting "stuck" indefinitely.BasePosixProcess.writeStdin(int, int)
to clear theuserWantsWrite
flag, if it's set, prior to callingonStdinReady
, and then only re-setuserWantsWrite
ifonStdinReady
returnstrue
WindowsProcess.writeStdin(int)
to use the same techniquecheckHandleValidity
was comparing the providedHANDLE
to the invalid handle's pointer, rather than comparing pointers from bothwantWrite()
request isn't "lost" if it happens during anonStdinReady
callbackwriteStdin
inBasePosixProcess
andWindowsProcess