8000 `wait-for-input` not returning on client disconnection · Issue #44 · usocket/usocket · GitHub
[go: up one dir, main page]
More Web Proxy on the site http://driver.im/
Skip to content

wait-for-input not returning on client disconnection #44

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.

Sign up for GitHub

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

Jump to bottom
Open
Zulu-Inuoe opened this issue Dec 30, 2018 · 1 comment
Open

wait-for-input not returning on client disconnection #44

Zulu-Inuoe opened this issue Dec 30, 2018 · 1 comment

Comments

@Zulu-Inuoe
Copy link

Hello! I noticed that given these functions:

(defun conn-server (&key
                     (interface nil)
                     (port 8080))
  (usocket:with-socket-listener (server interface port)
    (format t "Started server at ~A:~A~%" (usocket:get-local-address server) (usocket:get-local-port server))
    (usocket:with-connected-socket (client (usocket:socket-accept server))
      (format t "Client connected from ~A:~A~%" (usocket:get-peer-address client) (usocket:get-peer-port client))
      (format t "Waiting for input~%")
      (usocket:wait-for-input client))
    (format t "Client disconnected~%")))

(defun conn-client (&key
                      (host "localhost")
                      (port 8080))
  (usocket:with-client-socket (c nil host port)))

If I have a server running, and then call (conn-client), whether from the same process or a remote one, the server enters wait-for-input and never returns.

This may or may not be related to #43 .

This is SBCL 1.4.12 on 64-bit Windows 10.

Additionally, switching from usocket:wait-for-input to an open-stream-p on the socket stream seems to never return nil either.
Maybe I'm doing something logically wrong, but I'd love guidance if that's the case.

Thanks!
@Zulu-Inuoe
Copy link
Author

BTW I even killed the remote client process to make sure no there was no lingering socket in the background keeping the connection alive, and the server still stayed stalled.
Oddly enough, I could still connect to it

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
1 participant
@Zulu-Inuoe
0