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
