The test writes a string to the proxy stdin and expects to see the same string in stdout, as the debuggee runs getLine and then print on the result.
The test synchronizes with the interpreter by use of breakpoints, to hopefully give enough time for the desired string to make its way to the proxy output.
However even if the print .. is executed by the interpreter there's no guarantee the output string even gets written to the proxy's socket in time, as there's no synchronization mechanism in place for that.
The question is also whether the lack of synchronization is just a problem for the testing or for the proxy functionality in general.
In ghci you can expect putStrLn "foo" >> error "bar" to actually write "foo" to the terminal before the exception, while the hdb proxy might not manage.
Ideally we would have the debuggee block when flushing until the proxy completes the corresponding flush. Probably not feasible?
Maybe we could at least have the auxiliary debug session threads attempt to complete any pending tasks when destroyDebugSession is called though?
The test writes a string to the proxy stdin and expects to see the same string in stdout, as the debuggee runs getLine and then print on the result.
The test synchronizes with the interpreter by use of breakpoints, to hopefully give enough time for the desired string to make its way to the proxy output.
However even if the
print ..is executed by the interpreter there's no guarantee the output string even gets written to the proxy's socket in time, as there's no synchronization mechanism in place for that.The question is also whether the lack of synchronization is just a problem for the testing or for the proxy functionality in general.
In ghci you can expect
putStrLn "foo" >> error "bar"to actually write "foo" to the terminal before the exception, while the hdb proxy might not manage.Ideally we would have the debuggee block when flushing until the proxy completes the corresponding flush. Probably not feasible?
Maybe we could at least have the auxiliary debug session threads attempt to complete any pending tasks when destroyDebugSession is called though?