Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

WebSocket in child process gets stuck on Windows #13492

Closed
HertzDevil opened this issue May 22, 2023 · 1 comment · Fixed by #13908
Closed

WebSocket in child process gets stuck on Windows #13492

HertzDevil opened this issue May 22, 2023 · 1 comment · Fixed by #13908

Comments

@HertzDevil
Copy link
Contributor

Compile the following sources:

# hello.cr
require "http"

ws = HTTP::WebSocket.new("ws://127.0.0.1:55000/")
puts "Hello world"
# client.cr
require "http"

ws = HTTP::WebSocket.new("ws://127.0.0.1:55000/")
ws.send("x")
# server.cr
require "http"

ws_handler = HTTP::WebSocketHandler.new do |ws, ctx|
  ws.on_message do |message|
    p message
    begin
      process = Process.new({% if flag?(:win32) %} "hello.exe" {% else %} "./hello" {% end %}, [] of String, output: :inherit)
      p process
      p process.wait
    rescue ex
      p ex
    end
  end
end
server = HTTP::Server.new [ws_handler]
address = server.bind_tcp "127.0.0.1", 55000
puts "Listening on http://#{address}"
server.listen

Run server.exe and then client.exe. On Linux Hello world and Process::Status[0] will be printed on the server. On Windows the client returns, but hello.exe gets stuck and server.exe is also stuck waiting on it; subsequent runs of the client will get stuck.

I believe this is also why the playground doesn't work on Windows.

@HertzDevil
Copy link
Contributor Author

HertzDevil commented Oct 26, 2023

I believe this is just another consequence of Process#wait being a blocking call, due to LibC.WaitForSingleObject; if the on_message handler blocks the current thread, the HTTP::Server#listen fiber never gets to run, so the child process will never progress.

On POSIX Process#wait is indeed asynchronous and non-blocking, as it relies on SIGCHLD and Channel.

This issue was closed.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
Status: Done
Development

Successfully merging a pull request may close this issue.

1 participant