From @coke

See attached files.

I have seen variations of this problem in 2016.07, .08, and just today
with f648d3b / 67b6836 / 5108035 - however the issues with the most
recent version seem to happen even sooner. (2016.08, for example, It
looked like even more work was being done in the start block before
the hang occurred0

Run 'perl6 wtf.p6' - this starts the bailador server listening on port 7890.

Run the curl.sh command - you'll see an "A" in the log - if you
wait... no "B" appears.
Now run the curl.sh command multiple times - you'll see an "A" appear
for each request, but you won't get a "B" until a few requests have
been posted.

Remove the start block and restart - "B" comes back very quickly.

Revert wtf.p6, replace the slurp line with a "sleep 4" and rerun​: now
A still emits immediately with each curl request, but B emits for each
of those requests, just after the expected delay.

So, triggering the issue seems to require HTTP​::Easy's .run method
(used in Bailador), an async start block, and then additional IO in
the start block.

--
Will "Coke" Coleda

From @coke

curl.sh

From @coke

wtf.p6

From @jnthn

On Tue Sep 06 08​:58​:37 2016, coke wrote​:

See attached files.

I have seen variations of this problem in 2016.07, .08, and just today
with f648d3b / 67b6836 / 5108035 - however the issues with the most
recent version seem to happen even sooner. (2016.08, for example, It
looked like even more work was being done in the start block before
the hang occurred0

Run 'perl6 wtf.p6' - this starts the bailador server listening on port 7890.

Run the curl.sh command - you'll see an "A" in the log - if you
wait... no "B" appears.
Now run the curl.sh command multiple times - you'll see an "A" appear
for each request, but you won't get a "B" until a few requests have
been posted.

Remove the start block and restart - "B" comes back very quickly.

Revert wtf.p6, replace the slurp line with a "sleep 4" and rerun​: now
A still emits immediately with each curl request, but B emits for each
of those requests, just after the expected delay.

So, triggering the issue seems to require HTTP​::Easy's .run method
(used in Bailador), an async start block, and then additional IO in
the start block.

Attaching gdb to see where it was hanging showed up that the thread waiting to accept was preventing others from running GC. Fixed that in MoarVM. Also boiled the bug down to the test case now in roast as S32-io/socket-accept-and-working-threads.t, which covers it.

/jnthn

The RT System itself - Status changed from 'new' to 'open'

@jnthn - Status changed from 'open' to 'resolved'