You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
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.
Migrated from rt.perl.org#132983 (status was 'new')
Searchable as RT132983$
The text was updated successfully, but these errors were encountered: