Permalink
Browse files

Some more thoughts on concurrency; pthreads is an option

  • Loading branch information...
1 parent 3e3e38f commit 2c0b072a3abc6799ac8160bd25ce5f779e443857 @ohpauleez committed Feb 23, 2014
Showing with 9 additions and 2 deletions.
  1. +2 −1 README.mkd
  2. +7 −1 developer_log.mkd
View
@@ -108,7 +108,8 @@ Additional (but orthogonal) explorations include:
* This could be built on something like Julia's `llvmcall`
* Concurrency that supports Futures and CSP (state machines in parallel) at a minimum
* This will most likely be built on [Ray](https://github.com/richardhundt/ray) (libuv) or Richard Hundt's predecessor [Luv](https://github.com/richardhundt/luv) (potentially his *ray* branch)
- * You could add the worker queue, but not allow any global access (new or cloned Terra/Lua states per work item), in a share-nothing style.
+ * You could add the OS-Thread worker queue, but not allow any global access (new or cloned Terra/Lua states per work item), in a share-nothing style.
+ * Terra interops with pthreads just fine; You could always fall back to low-level threading if appropriate.
The language is never concerned with:
View
@@ -523,6 +523,12 @@ The tradeoff here is that in order to use the concurrency/async stuff, you *alwa
have to accept that the libuv loop will be running under the hood.
Another tradeoff is that this still doesn't satisfy running `core.async`'s
state machines in parallel (at least no solution that is immediate to me right
-now).
+now). The core.async + fibers could be confusing (different systems at different
+levels with slightly-different-but-very-close semantics).
+Terra also has no issue with using pthreads directly, so building an executor
+pool at that level is an option, but this puts incredible strain on what you
+can do in Terra for AOT/generated code and what you can do during LuaJIT runtime
+stuff.
+

0 comments on commit 2c0b072

Please sign in to comment.