Interesting, Thread.exit() just calls to pthread_exit; I wonder if there is some other sort of underlying failure there.

I don't have a pi handy to test this out; but the one differential between the Darwin implementation of the objective-c version and the swift-corelibs-foundation version is that the thread attributes for the objective-c version has a few initializers

    pthread_attr_init(&ivars->attr);
    pthread_attr_setscope(&ivars->attr, PTHREAD_SCOPE_SYSTEM);
    pthread_attr_setdetachstate(&ivars->attr, PTHREAD_CREATE_DETACHED);

Comment by Joe (JIRA)

@phausler: I believe I can patch these initializers in and kick the tires. I'll provide the patch that I came up with and report back.

Comment by Joe (JIRA)

@phausler: I applied the general patch into NSThread.swift and am running it now. Up to 300 threads created and exited on the Pi 3. Will let it run up a bit higher and then provide a PR. For reference using your code as a hint, Linux creates threads as JOINABLE by default, thus with no one joining the app was leaking thread resources. Changing to DETACHED resolved that. I don't believe SCOPE_SYSTEM has any effect as this apparently is the only scope actually supported on Linux.

References:
http://man7.org/linux/man-pages/man3/pthread_attr_setscope.3.html
https://developer.apple.com/library/ios/documentation/Cocoa/Conceptual/Multithreading/CreatingThreads/CreatingThreads.html#//apple_ref/doc/uid/10000057i-CH15-SW3
"Setting the Detached State of a Thread
Most high-level thread technologies create detached threads by default. In most cases, detached threads are preferred because they allow the system to free up the thread’s data structures immediately upon completion of the thread. Detached threads also do not require explicit interactions with your program. The means of retrieving results from the thread is left to your discretion. By comparison, the system does not reclaim the resources for joinable threads until another thread explicitly joins with that thread, a process which may block the thread that performs the join.

You can think of joinable threads as akin to child threads. Although they still run as independent threads, a joinable thread must be joined by another thread before its resources can be reclaimed by the system. Joinable threads also provide an explicit way to pass data from an exiting thread to another thread. Just before it exits, a joinable thread can pass a data pointer or other return value to the pthread_exit function. Another thread can then claim this data by calling the pthread_join function."

Comment by Joe (JIRA)

Fix looks good. Shortened delay of creation/destruction of threads:

import Foundation
import Glibc

var counter = 0
while true {
  usleep(100)
  counter = counter + 1
  let t = Thread(){
    print("STARTED:\(counter)")
    usleep(50)
    print("EXIT:\(counter)")
    Thread.exit()
  }
  print("START:\(counter)")
  t.start()
}

This is running steady state on a Pi 3 with over 1 million threads created and destroyed. That was compared to ~250 without the patch.

Comment by Joe (JIRA)

#425 PR submitted.

Pi 3 at 1.7M thread creates/destroys.

Comment by Joe (JIRA)

Merge complete, will rebuild, verify, and close.

Comment by Joe (JIRA)

Verified fixed against e74f745 Closing.