Re: lua_Alloc alternative recommendations?

[Graham Wakefield <lists@...>]

It was definitely realloc, in the high priority thread of an audio  
callback.  I fixed the problem (no more crashes) by disabling garbage  
collection at the start of any Lua calls in this thread, and re- 
enabling at the end (only 2 C functions in my case), and using a  
pthread mutex lock to safely call the garbage collector periodically  
from a safe, low-priority thread.

Some example code follows.  I use two Lua states and a mutex in order  
to share Lua data safely between two threads (it was a requirement  
for my application).  Of course, the way I'm doing this might not be  
ideal, and if anyone wants to point out a glaring error I make,  
please do!

lua_State * L = lua_open();
lua_State * Lpriority = lua_newthread(Lidle);
pthread_mutex_t	Lmutex;
pthread_mutex_init(&Lmutex, NULL);

// idle low priority thread function:
void lua_idle()
{
	pthread_mutex_lock(&Lmutex);		// lock can block, but that's ok in  
the idle thread

	//.. do stuff with L
	// 	keep it short, to minimize mutex lock time
	//	if lengthy activity is needed, probably a third temporary lua_State
	//	could be used instead, and results xmove'd to L within the mutex  
lock

	pthread_mutex_unlock(&Lmutex);
}

// high priority thread function:
void lua_priority()
{
	lua_gc(Lpriority, LUA_GCSTOP, 0);			// disable gc during this  
function call

	if (pthread_mutex_trylock(&Lmutex)) 			// trylock does not block
	{
		lua_xmove(L, Lpriority, lua_gettop(L));		// copy stack from L to  
Lpriority
		pthread_mutex_unlock(&Lmutex);			// finished working with L

		//.. do stuff with Lpriority,
		//	safely knowing that it will not collect garbage
		// 	and that the lua_State will not be corrupted by calls to  
lua_idle()

		
	}
	lua_gc(Lpriority, LUA_GCRESTART, 0);		// re-enable gc
}


On Dec 13, 2006, at 11:59 AM, Peter Pimley wrote:

> "avoid using free/realloc etc, which I assume is the cause of the
> crash."
>
> Hi,
>
> What I'd do first is to write a wrapper that just calls free/realloc,
> but logs* each call and alerts* you if it fails.  At least then you'd
> know for sure that this is where the trouble lies, rather than  
> assuming
> it.
> (* How you do these will depend on your hardware of course)
>
> The example function (http://www.lua.org/manual/5.1/manual.html#3.7)
> could be modified pretty easily.
>
> The thing is; if realloc IS failing then you're in trouble  
> whichever way
> you look at it.  Are you sure it's not some other part of your program
> leaking or fragmenting memory?
>
> Peter
>
> ______________________________________________________________________ 
> ____________________________________________________________________
> Information contained in this e-mail is intended for the use of the  
> addressee only, and is confidential and may be the subject of Legal  
> Professional Privilege.  Any dissemination, distribution, copying  
> or use of this communication without prior permission of the  
> addressee is strictly prohibited.The views of the author may not  
> necessarily constitute the views of Kuju Entertainment Ltd. Nothing  
> in this email shall bind Kuju Entertainment Ltd in any contract or  
> obligation.
>
> The contents of an attachment to this e-mail may contain software  
> viruses which could damage your own computer system. While Kuju  
> Entertainment has taken every reasonable precaution to minimise  
> this risk, we cannot accept liability for any damage which you  
> sustain as a result of software viruses. You should carry out your  
> own virus checks before opening the attachment.
>
> ______________________________________________________________________ 
> ____________________________________________________________________
> This email has been scanned by the MessageLabs Email Security System.
> For more information please visit http://www.messagelabs.com/email
> ______________________________________________________________________ 
> ___________________________________________________________________