Re: [Proposal] Thread Metatable

[Andrew Starks <andrew.starks@...>]

On Tuesday, June 23, 2015, Philipp Janda <siffiejoe@gmx.net> wrote:
> Am 23.06.2015 um 22:27 schröbte Rena:
> > I agree, for numbers would be odd, but for threads seems natural. I
> > was actually surprised that they don't have `__index = _G.coroutine`
> > already.
>
> There are only two functions in the coroutine library that you could call with method syntax (`status` and `resume`). All other functions don't take a coroutine as first parameter.
>
> Philipp

I use this in my threadex library:

local t2 = threadex.create()

local t = threadex:running()

t:status()

--"running"

t:isyieldable()

--true

t:yield()

t2:resume()

--...

-----

Then I went further by adding every thread to the threadex.threads table. Then I can:

threadex:step() --resume next thread
threadex:cycle() --resume all threads once

threadex:loop() --resume all until all are dead. Should be join?

Also, each thread also has a threads table, so this nests. I then added an error handler, but I didn't finish it yet. 

My report:

I love it. It's really natural with sockets and req/rep/restful stuff. Every time I think I can blame it for a problem, I can't, so that's good? :)

It's just that it is very specialized to me. It works for this kind of concurrency, but there are more sophisticated ones that are made differently. Something like this would make a statement about how concurrency should be done and that's unwise. Concurrency is often decided by something else (iocp) so the ideal model varies. 

That's my impression, anyway.