Firstly, I would like to clarify that I am aware of the distinction between cooperative multitasking (coroutines/fibers) and true OS threads. Also, I would prefer to avoid answers questioning why I want to know, or whether or not one implementation is more performant than the other in which particular situations, etc. Let’s assume that I have a valid reason for asking the question and the only thing that interests me is the specific answer.
I was curious whether or not the underlying implementation of the WWW class spawns a new system thread to manage the download, or whether the download is processed in the main thread.
According to this forum thread: ( http://forum.unity3d.com/threads/67879-Is-Unity-multi-threaded ) unity is single threaded by design to support single core devices, but I have not found any official documentation stating such. Can anyone verify this with official documentation? EDIT: Further in the thread it is mentioned that WWW is one of the only classes that make use of threads…
Update: I attempted to test by using Activity Monitor to watch process thread count while triggering multiple web requests. No new threads were spawned. I thought there could be some heuristic to prevent spawning a thread for small files, or that the threads were being created and destroyed so quickly they weren’t displaying in Activity Monitor, so I generated a 1mb garbage file and loaded it and it still did not spawn threads. I served the file from a node.js app in case it was prevent thread spawning for local disk access (URIs with file://). No threads spawned. I served it from an ubuntu vm in case it was optimizing loading from localhost. No threads spawned. Not looking good.
Update 2: Using Process.GetCurrentProcess().Threads.Count I attempted to monitor threads internally. No threads are spawned. This only means that Unity is not spawning threads within the managed CLR though, not that the application is not spawning threads at all. I’m not sure the internal implementation here, but this is looking more and more like a dead end. At least on Mac there doesn’t seem to be any threads spawning in the .NET runtime, or as far as I can tell based on procmon either.
Update 3: Process.GetCurrentProcess().Threads.Count is unreliable (Am I using it wrong?). I spawned a thread manually and it continued to return 0, even though ActivityMonitor showed a new thread being added to the Unity process. I added frame delays to give the CLR a chance to register the creation of the thread before querying and it still returned 0. Weird. This does mean, at least, that Unity supports spawning threads on OSX through the Mono runtime. More tests to follow…
Update 4: I thought there might be some implementation differences between the generated standalone and the runtime, or Unity was thread pooling and the threads were never being released. This looks likely! I generated an app file, and it looks like right on cue, 10 threads are spawned when I generate 10 www requests, then they go away afterwards. Maybe not definitive, but good enough for me I guess, unless a developer wants to clue me in on the actual answer.