Reusing a Thread

classic Classic list List threaded Threaded
9 messages Options
Reply | Threaded
Open this post in threaded view
|

Reusing a Thread

William Ahern-2
If a thread returns from lua_resume()--not by yielding--but I've stored
the thread in the registry to prevent garbage collection, can I re-issue
lua_resume() rather than creating a new thread?

-- 
William Ahern <[hidden email]>


--------------------------------------------------
This message was scanned for Spam, Spyware and Viruses
For more information, please visit:
http://www.barracudanetworks.com


Reply | Threaded
Open this post in threaded view
|

Re: Reusing a Thread

D Burgess-4
Can you? yes I have done this. It seems to work unless and
exception has been thrown.
Are you supposed to? I dont know.

David B

If a thread returns from lua_resume()--not by yielding--but I've stored
the thread in the registry to prevent garbage collection, can I re-issue
lua_resume() rather than creating a new thread?

Reply | Threaded
Open this post in threaded view
|

Re: Reusing a Thread

Roberto Ierusalimschy
> >If a thread returns from lua_resume()--not by yielding--but I've stored
> >the thread in the registry to prevent garbage collection, can I re-issue
> >lua_resume() rather than creating a new thread?
>
> Can you? yes I have done this. It seems to work unless and
> exception has been thrown.
> Are you supposed to? I dont know.

No problem. Once you clear the returned values from the stack, the
thread is as good as a new one. In case of errors, it does not unwind
the stack (so you can inspect it for debugging), and so you cannot reuse
the thread (as you said). (Maybe we will add a "reset" call to clear the
thread after an error...)

-- Roberto

Reply | Threaded
Open this post in threaded view
|

Re: Reusing a Thread

Mark Hamburg-4
on 8/18/06 12:12 PM, Roberto Ierusalimschy at [hidden email] wrote:

>>> If a thread returns from lua_resume()--not by yielding--but I've stored
>>> the thread in the registry to prevent garbage collection, can I re-issue
>>> lua_resume() rather than creating a new thread?
>> 
>> Can you? yes I have done this. It seems to work unless and
>> exception has been thrown.
>> Are you supposed to? I dont know.
> 
> No problem. Once you clear the returned values from the stack, the
> thread is as good as a new one. In case of errors, it does not unwind
> the stack (so you can inspect it for debugging), and so you cannot reuse
> the thread (as you said). (Maybe we will add a "reset" call to clear the
> thread after an error...)

A reset call would be really useful. We try to cache threads, but we have to
assume that they are invalid after an error.

Mark


Reply | Threaded
Open this post in threaded view
|

Re: Reusing a Thread

Mike Pall-64
In reply to this post by Roberto Ierusalimschy
Hi,

Roberto Ierusalimschy wrote:
> (Maybe we will add a "reset" call to clear the
> thread after an error...)

Yes, please. And please make this a spec requirement for thread
reuse even in case of proper termination (although not enforced
by the implementation).

[
With the latest Coco patches threads are _not_ reusable, even
after proper thread termination. I assumed this was "undefined"
by the language spec and so didn't bother to add a (tricky)
workaround. A lua_clearthread() (calling luai_userstateclear())
would simplify this.
]

BTW: Another one for the wishlist: lua_cleartable(L, narr, nrec).
Use case: a common table referenced in dozens of upvalues needs
to be cleared fast. Replacing it with a new table is not an
option because then I'd have to store all affected closures
somewhere. Iterative clearing is annoying/slow. Don't know if
this is a popular wish, though.

Bye,
     Mike

Reply | Threaded
Open this post in threaded view
|

Re: Reusing a Thread

Mark Hamburg-4
on 8/18/06 1:09 PM, Mike Pall at [hidden email] wrote:

> BTW: Another one for the wishlist: lua_cleartable(L, narr, nrec).
> Use case: a common table referenced in dozens of upvalues needs
> to be cleared fast. Replacing it with a new table is not an
> option because then I'd have to store all affected closures
> somewhere. Iterative clearing is annoying/slow. Don't know if
> this is a popular wish, though.

I find myself clearing tables on occasion though I've been trying to train
myself to let them just become garbage.

Mark


Reply | Threaded
Open this post in threaded view
|

Re: Reusing a Thread

Javier Guerra Giraldez
In reply to this post by Mike Pall-64
On Friday 18 August 2006 3:09 pm, Mike Pall wrote:
> BTW: Another one for the wishlist: lua_cleartable(L, narr, nrec).
> Use case: a common table referenced in dozens of upvalues needs
> to be cleared fast. Replacing it with a new table is not an
> option because then I'd have to store all affected closures
> somewhere. Iterative clearing is annoying/slow. Don't know if
> this is a popular wish, though.

i'd like to do that from Lua code.  when optimising the inner loops in 
Xavante, i found that eliminating even a single table creation made a 
perceptible difference.  unfortunately, there are very few structures that 
should persist from one request to the next, so it still has to create 
several new tables before servicing the request.  clearing them instead of 
recreating should be faster.

but, it's just an optimisation detail.  not critical, and definitely not 
reason enough in itself.

-- 
Javier

Attachment: pgp0UI7MFla_K.pgp
Description: PGP signature

Reply | Threaded
Open this post in threaded view
|

Re: Reusing a Thread

D Burgess-4
In reply to this post by Roberto Ierusalimschy
Roberto Ierusalimschy wrote:
(Maybe we will add a "reset" call to clear the
thread after an error...)

If you want someone to test it, I have can do it. I have
a good C test case.

DB

Reply | Threaded
Open this post in threaded view
|

Re: Reusing a Thread

Javier Guerra Giraldez
On Saturday 26 August 2006 9:14 am, D Burgess wrote:
> Roberto Ierusalimschy wrote:
> > (Maybe we will add a "reset" call to clear the
> > thread after an error...)
>
> If you want someone to test it, I have can do it. I have
> a good C test case.

Xavante could be very benefited by this capability!  or, more precisely 
coxpcall(), which reimplements pcall() using coroutines.  it has a very big 
overhead because it has to create a new coroutine each time.  being able to 
pool and reuse them would be great

-- 
Javier

Attachment: pgpjZeC91qRQq.pgp
Description: PGP signature