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

Jump to bottom

Roast S32-io/IO-Socket-Async.t test fails WSL - listen "already in use" test #6678

Open
p6rt opened this issue Mar 15, 2018 · 2 comments
Open

Roast S32-io/IO-Socket-Async.t test fails WSL - listen "already in use" test #6678

p6rt opened this issue Mar 15, 2018 · 2 comments

Comments

@p6rt
Copy link

p6rt commented Mar 15, 2018

Migrated from rt.perl.org#132983 (status was 'new')

Searchable as RT132983$
@p6rt
Copy link
Author

p6rt commented Mar 15, 2018

From @ronaldxs

Roast S32-io/IO-Socket-Async.t has a test for a second tap on a Supply
from listen which is supposed to quit right away. On WSL (windows
subsystem linux) the second tap does not quit and awaiting for the
failure runs past the 5 second Promise waiting for the quit and then
fails. The message for this test is 'Address already in use results in
a quit'.

Not sure where/what the problem is and so not suggesting fudging the
test.

@p6rt
Copy link
Author

p6rt commented Oct 9, 2018

From rdbingham@verizon.net

Regards sockets and listen calls in P6 IO-Socket-Async​: is the "a
second [listen] tap [on a socket] should fail" a specification (a
specified behavior of the particular P6 module classes/objects
involved) or a hidden assumption on the operating environment
(operating system)?  If the former presumably there is an
OS-independent data structure in the P6 runtime address space to
keep track of sockets and their listen state, that is, no
low-level system call is used to detect duplicate listen() calls,
and behavior (test passes on all OSs or none) should be consistent.

If the latter, there are operating environments that happily
accept multiple, pending listen() operations on the same socket.
Depending on how the second tap test is structured, the test
could fail with a Promise timeout because multiple OS listen()
calls on the same socket can block without OS error.  In fact, I
have seen apps that use this OS feature as a simple worker
dispatch mechanism.  A Leader opens a socket then creates
multiple workers each of which is an OS runqueue schedulable
entity, each inherits a handle or descriptor to the socket then
each does a blocking listen(). A connection arrives and the OS
wakes up an arbitrary listen()er blocked on the socket listen()
wait channel in kernel space and hands it the connection. No
complex dispatch code in the Leader needed.

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
@p6rt