* Store the job's thread in `JobData`.
Since we're storing more and more in `JobData`, and the background thread only needs three bits of that data, I added those to `ThreadEvent` so we don't have to pass the full object. This may improve performance in HTML5 specifically, where passing a class instance incurs an overhead.
* Allow a single `ThreadPool` to run jobs in both modes.
* Remove unnecessary `@:forward.new`.
* Improve check for whether to call `Thread.returnMessage()`.
Now that thread pools can manage both types of job at once, we can't rely on `mode` to determine whether we're on a background thread. Honestly, I shouldn't have relied on it in the first place.
* Improve `ThreadPool.isMainThread()`.
No need to set `__mainThread` based on `isWorker()` when `isWorker()` already gives the information we're after.
* Correct and clarify documentation.
* Start new jobs immediately when a slot opens up.
For single-threaded jobs, this means a pool can now handle multiple per frame. For multi-threaded jobs, this only slightly reduces the delay between jobs.
* Fix missing function call.
* Add missing import.
Forgot this when overriding the "send" functions.
* Simplify comment.
It's a private variable, so all it really needs to do is mention the location it gets used.
* Don't count the main thread in `currentThreads`.
Plus, alphabetize the variables.
In 8.2.0, a single-threaded pool would report `currentThreads == 1` when running a job, meaning it counted the main thread. But in retrospect, this was both redundant (with `activeJobs`) and unexpected, so I'm counting it as a bug.
* Update documentation.
* Remove redundant check.
All the jobs in `__multiThreadedJobs` are already known to be running in multi-threaded mode. This is left over from when pools were locked to a single mode.
* Handle error case differently.
We still need to throw an error when `mode` is `MULTI_THREADED`, but this can now vary per job, so the check must happen during `run()`.
Also, the old error message was out of date. You can't pass a function to the `ThreadPool` constructor.
* Remove unnecessary `#if`s.
On other targets, it will return `true`, which will be inlined and optimized out. The conditional compilation just added clutter.
* Rewrite `ThreadPool` to use `Deque` on native targets.
Using the flag `lime_threads_deque` to distinguish between this and the old approach. Hopefully someday we can remove this flag, once we implement something akin to `Deque` in HTML5.
That aside, the hardest part is keeping track of the state of each thread. That's why there's so much more complexity: whenever the main thread sends a message to a worker, it needs to wait for confirmation, but also not send any more messages while waiting. And the code that tracks all this needs to work in both modes (with and without `Deque`).
* Bug fix: `firstLoop = false` can get skipped.
* Fix misplaced `#if`.
* Add missing `#if`.
* Make sure all events are received before removing the update listener.
After all jobs are done, threads will send `EXIT` events. These must be processed before removing `__update`, otherwise they'll linger in the queue until the next job starts.
* Keep better track of how many threads are idle.
Previously, while a thread was exiting, `ThreadPool` could think it was still idle. This would cause it not to spin up a new thread for the next job, leading to a pending job with no threads available to handle it.
* Remove redundant code.
* Fix null pointer error.
* Fix bugs in `cancel()` and `cancelJob()`.
* Don't shut down a `ThreadPool` while work events are queued.
Co-authored-by: Barış Yıldırım <25794892+barisyild@users.noreply.github.com>
* Add missing `#if`.
---------
Co-authored-by: Barış Yıldırım <25794892+barisyild@users.noreply.github.com>
The former was unclear about how the dependency would relate to web workers. Would it only be available to workers? Would it automatically spin up a worker?
`allow-web-workers` isn't 100% perfect, but it implies the correct answers to the questions above (no and no) and isn't too long.
It took a lot of work to get web workers to work, but web workers finally work!
`transferList` doesn't seem to work, though. It makes the object
inaccessible as expected, but it doesn't seem to affect performance.
Not well-tested yet, especially the web workers.
In addition to web workers, this completely rewrites both
`BackgroundWorker` and `ThreadPool`. It adds thread safety via the
`WorkOutput` object, adds flexibility by making `BackgroundWorker` build
off `ThreadPool`, and exposes an `eventSource` variable that tells
listeners which job dispatched a given event.
This improves the old web worker implementation by reusing the _entire_
JS file. This is slower but ensures that all classes are available,
simplifying the end user experience. Web workers are now forbidden from
using instance functions, which also simplifies things. And finally, the
code attempts to restore the prototypes of all class instances passed
across threads, though this relies on the exact way Haxe generates
JavaScript, and may not work in Haxe 3 or Haxe 5.
Lime requires the `Deque` class to target HashLink, which only
became available in Haxe 4. If you try, Lime should at least let
you know what's wrong.
Closes #1403... at least for now.
This reverts commit 8d1ff873d8.
Revert "Binding fix"
This reverts commit c606ec5139.
Revert "Add support for HL libraries"
This reverts commit 6b49f4d240.
Revert "Minor fixes"
This reverts commit dcacb9f04a.
Revert "Compile fixes"
This reverts commit 3b9e572f8b.
Revert "Sync with Haxe std library (remove some overrides)"
This reverts commit c05061c970.
Revert "Initial support for HL target in tools (for testing)"
This reverts commit 1dadbb725c.
