[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: Re: [PATCH] Proposal: asynchronous coroutines and multithreading
- From: Tim Hill <drtimhill@...>
- Date: Sat, 3 Jan 2015 00:23:03 -0800
> All of this is built with pthreads, using python-style Global Interpreter Lock
> (lua_lock and lua_unlock helped a lot in the process). Someone with proper
> knowledge of the lua runtime and internals (unlike me) would probably be able to
> rewrite the thing using per-state mutexes in a lot of places
> There isn't any real reason lua shouldn't support threads like these.
> - New dependency? Pthreads are a part of POSIX, and surely it won't be too hard
> to port to That One Platform No One Likes.
> - No one likes unnecessary complications, new types, new fundamental concepts?
> This thing reuses an existing concept - coroutines.
> - Performance impact? If threads aren't used, no unnecessary code is ever
> executed so there's no slow down. If they are, as of right now the slowdown
> is only about 5%, and if rewritten to use per-state mutexes it would approach
But if you are using a global lock what real concurrency are you actually getting? I suspect most of the time the threads will be blocked waiting for that mutex and so the whole thing will degenerate into an expensive form of serialization. Have you tried a simple benchmark using (say) a couple of compute-bound for loops to see how much faster they run vs a single loop?