Right now the following are equivalent:
and
The former was added as an after thought to allow anonymous functions, but the making of the threads module brought to light the issue that functions are living entities. When you define a function its also implementing it. This means that multiple threads calling the same function causes a trampling, especially with loops. Thread A starts a loop a moment before thread B, and when thread B modifies the counter, thread A loses its place.
This task is to distinguish the above statements into two separate entities. The latter will be solely a definition that when called, creates a unique copy of itself to use for execution.
I picture the latter as having its own alternative to function_info_s that has a thread safe "queue" of copies. When called, it will grab a copy off the queue to be used for execution.The function should keep track of how often it is called so it can decide if it should queue more objects if its a hot function.
Since the queue will be thread safe once it hits a certain number and needs to re-queue copies, it can spawn a thread to generate the copies that inserts them once copies are completed. We want to spin this off because it could cause substantial overhead on the active thread.
This will lay the foundation for bytecode-constructed functions that work within the interpreter
Right now the following are equivalent:
and
(fn x [] (<- 0))The former was added as an after thought to allow anonymous functions, but the making of the threads module brought to light the issue that functions are living entities. When you define a function its also implementing it. This means that multiple threads calling the same function causes a trampling, especially with loops. Thread A starts a loop a moment before thread B, and when thread B modifies the counter, thread A loses its place.
This task is to distinguish the above statements into two separate entities. The latter will be solely a definition that when called, creates a unique copy of itself to use for execution.
I picture the latter as having its own alternative to function_info_s that has a thread safe "queue" of copies. When called, it will grab a copy off the queue to be used for execution.The function should keep track of how often it is called so it can decide if it should queue more objects if its a hot function.
Since the queue will be thread safe once it hits a certain number and needs to re-queue copies, it can spawn a thread to generate the copies that inserts them once copies are completed. We want to spin this off because it could cause substantial overhead on the active thread.
This will lay the foundation for bytecode-constructed functions that work within the interpreter