What would cause an interactive shell to hang on shell.write?

General
1

Got a bug report from a user this morning with a hang and a sample. The sample shows that it’s 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 it’s 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 it’s 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 it’s possible that it had quit between my checking it and my sending the next packet of data to it.

2

You have developed the console application?
If so, do you use the Input() function in a loop?

3

I have also developed the console application. The code is basically just this:

while true
dim received as string = stdin.readAll

// do some trivial stuff that should not take long at all

app.doEvents( 100)
wend

it would be nice to be able to get data available events for stdin. Did I miss something about that in the docs?

4

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

5

I will give that a try thank you, since it’s not very repeatable I may not know for a long time if that solves the problem or not…

6

You could try to lower the doevents time to the default (10)

7

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 I’ve done in the past 100ms makes it show up as 0% or at most 0.1% on the activity monitor when it’s not actually doing anything. This is all assuming that a write to the shell in the host program can become blocking if the shell hasn’t bothered to read it and let the buffer fill up. Without knowing if that is true or not I’d rather not decrease it’s 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 doesn’t actually read anything and see when the write starts to block, or if it does. I’m off to do that I suppose :slight_smile: Thank you!