Got a bug report from a user this morning with a hang and a sample. The sample shows that its basically hung at writing to an interactive shell. I check to make sure the shell is running via the .isRunning property before I try to write to it. The messages being written are ascii and very small, just a few bytes. Sending the data is in a timer that fires twice a second, so I suppose its possible the helper app, that is another Xojo app, could have hung up and stopped reading from stdin? Would those buffers fill up and start blocking until the shell app read them? What else could cause an interactive shell to hang up the main thread with a call to write?
The sample shows that the app is calling to runLoopDoTimer, then I see my class name and the method name that the timer is assigned to and then Shell.write, an unknown address in Shell.dylib and the last thing is write (in libsystem_kernel.dylib) and the entire number of samples shows it going all the way down to that so its basically stuck there hung up.
I suppose I could switch to a IPC Socket for the connection between the 2 if this becomes a thing… but I feel like an interactive shell should not block on write. There are no errors from the background app and it appeared to be running properly when this happened but its possible that it had quit between my checking it and my sending the next packet of data to it.
You have developed the console application?
If so, do you use the Input() function in a loop?
I have also developed the console application. The code is basically just this:
dim received as string = stdin.readAll
// do some trivial stuff that should not take long at all
it would be nice to be able to get data available events for stdin. Did I miss something about that in the docs?
This may seem odd, but I’ve run into issues in console tools where setting the value of the property in its Dim statement has odd results. Change your input to:
Dim received As String
received = stdin.ReadAll
I will give that a try thank you, since its not very repeatable I may not know for a long time if that solves the problem or not…
You could try to lower the doevents time to the default (10)
If I do that then it will be using up a noticeable portion of a CPU doing nothing but just spinning there when there is no data. For most other such things Ive done in the past 100ms makes it show up as 0% or at most 0.1% on the activity monitor when its not actually doing anything. This is all assuming that a write to the shell in the host program can become blocking if the shell hasnt bothered to read it and let the buffer fill up. Without knowing if that is true or not Id rather not decrease its idle time. I suppose the best way to prove that is to do some tests. I can certainly write a test host and a test background app that doesnt actually read anything and see when the write starts to block, or if it does. Im off to do that I suppose Thank you!