I have the following code on Linux:

local shpipe=io.popen("sh -s","w")
shpipe:setvbuf("no")
local round=0
while true do
        shpipe:write("echo test > fifo\n")
        shpipe:flush()
        print("Before")
        local fifoh=io.open("fifo","r")
        print("After")
        local rd=fifoh:read("*l")
        fifoh:close()
        round=round 1
        print(round)
end

Before you run the code make sure you run "mkfifo fifo" in your current directory as this code expects a named pipe with that name.

You will notice that the code gets randomly stuck (after a random number of iterations) while trying to simply open the named pipe.

I know that working with pipes is tricky but I don't see why it would block there. Checking the process tree it seems that, when the problem occurs, "sh -s" was probably more slow than usual in trying to start up "echo". But I don't see why this would be a problem. Opening a named pipe which is not opened by someone on the other side should block the process that tries to open it. I even tested it with two lua processes and this is the case, the one who tried to open for read access was blocked until the other lua process tried to open the named pipe for write access. And vice versa. In other words, whether my script is the first to open its end of the pipe, or sh/echo is first, it shouldn't matter. But the code above shows that it does matter and I don't have a clue why.

My question to any Linux gurus here is: If the Lua process gets blocked on IO, like it does, is there ANY reason for child processes to be paused or denying CPU time? Based on what I know, no, children should keep running, sh should keep running and echo should run but maybe I'm wrong. If children pause when the parent blocks on IO then it would explain why echo never starts up, never opens the other side of the named pipe, and the parent then would block forever.

I tried to further delay the execution of "echo" and hopefully the opening of the pipe for write by adding a "sleep 1;" right before echo but it doesn't make the deadlock certain even though Lua should be opening the pipe before sh does. So.... it's not about the order of who opens the pipe? If that's not the problem then what else could be different? Why else would sh/echo decide to never open the named pipe?