From @hoelzro

If I do something like this​:

  for ^1000 {
  Thread.start({}).join;
  }

MoarVM will raise a SIGABRT. The reason is that MoarVM+libuv is allocating control pipes (or something like that), MVM_tc_destroy is never called for a thread's ThreadContext after it's joined, the process quickly runs out of file descriptors, and libuv calls abort() after getting a ENFILE.

From @hoelzro

On 2015-09-03 06​:42​:59, rob@​hoelz.ro wrote​:

If I do something like this​:

for ^1000 {
Thread.start({}).join;
}

MoarVM will raise a SIGABRT. The reason is that MoarVM+libuv is
allocating control pipes (or something like that), MVM_tc_destroy is
never called for a thread's ThreadContext after it's joined, the
process quickly runs out of file descriptors, and libuv calls abort()
after getting a ENFILE.

My mistake; that example doesn't work! This one should​:

  for ^1000 { Thread.start(-> {}).join; }

From @jnthn

On Fri Sep 04 08​:06​:36 2015, rob@​hoelz.ro wrote​:

On 2015-09-03 06​:42​:59, rob@​hoelz.ro wrote​:

If I do something like this​:

for ^1000 {
Thread.start({}).join;
}

MoarVM will raise a SIGABRT. The reason is that MoarVM+libuv is
allocating control pipes (or something like that), MVM_tc_destroy is
never called for a thread's ThreadContext after it's joined, the
process quickly runs out of file descriptors, and libuv calls abort()
after getting a ENFILE.

My mistake; that example doesn't work! This one should​:

for ^1000 \{ Thread\.start\(\-> \{\}\)\.join; \}

Fixed, and added S17-lowlevel/thread-start-join-stress.t to try and ensure we don't regress on this. Tested the fix on Windows and Linux.

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

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