Re: [PATCH] Proposal: asynchronous coroutines and multithreading

[Tim Hill <drtimhill@...>]

> 
> 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
>  zero.
> 

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?

—Tim