Skip Menu |
Report information
Id: 132983
Status: new
Priority: 0/
Queue: perl6

Owner: Nobody
Requestors: rdbingham [at] verizon.net
ronaldxs <ronaldxs [at] software-path.com>
Cc:
AdminCc:

Severity: (no value)
Tag: (no value)
Platform: (no value)
Patch Status: (no value)
VM: (no value)



To: rakudobug [...] perl.org
Subject: Roast S32-io/IO-Socket-Async.t test fails WSL - listen "already in use" test
From: Ronald Schmidt <ronaldxs [...] software-path.com>
Date: Thu, 15 Mar 2018 10:25:55 -0400
Download (untitled) / with headers
text/plain 431b

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.

From: BloomingAzaleas <rdbingham [...] verizon.net>
Date: Mon, 8 Oct 2018 23:00:45 -0400
Subject: RT#132983 comment
To: rakudobug [...] perl.org
Download (untitled) / with headers
text/plain 1.3k
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.


This service is sponsored and maintained by Best Practical Solutions and runs on Perl.org infrastructure.

For issues related to this RT instance (aka "perlbug"), please contact perlbug-admin at perl.org