threads question

[Michael C. Shultz]

On Wednesday 16 March 2005 01:40 pm, you wrote:
> >this works perfectly because I moved MGPMrUpgrade into
> >the same .c file so it would be a static function:
> >
> >structProperty* property;
> >pthread_t               threads[NTHREADS];
> >pthread_create( &threads[0], NULL, zzMGPMrUpgrade, property );
> >When I use MGPMrUpgrade from a shared library the function runs
> >yet property isn't being passed!
>
> What do you mean by it not being passed? Does your function receive a
> NULL value for the parameter instead of the pointer? (Assuming no
> dirty tricks, the function would by definition always be passed
> *some* value, though it may be NULL.)

I finally figured out what I was doing wrong, it was my lack of 
understanding threads. here is what I was doing:

int main()
{
	int(*fpt)(structProperty*);

	fpt= ThreadFunct;
	runFunc( fpt ); 
}

int Funct( int(*fpt)(structProperty*) )
{
	pthread_t		threads[NTHREADS];
	structProperty* property

	pthread_create( 
		&threads[0],
		NULL, 
		int(*fpt)(structProperty*)ThreadFunct,
		(void*)property );
}

Thats just a rough outline, anyways property was going out of scope
while the thread was running, just as Zera and Daniel warned me about.

I just moved the declaration into main and switched tool kits to motif
from GTK and all is well.

Basically I could not pass a function pointer as a call back with 
paramaters from a GTK button through to actually running the function. 

That is why I moved the declaration of property down a level in the 
first place, didn't occur to me how vital scope is when using threads 
though.

Switched to motif and everything passes flawlessly.  I wish GTK had 
either better docs or wasn't broken, not sure what the problem is 
there, probably my lack of understanding again but I don't care, motif 
will work for what I need to do.

If it wasn't for Zera and Daniel's questions I would have never figured 
this out!

>
> > Hmmm, should I'll try making "property" global then passing a copy
> > of it to each thread?  I think that will guarantee it stays valid.
>
> Since you are asking about makint it global - what is it *now*? It
> would have to be either global, dynamically allocated, or on the
> stack. If it's on the stack, things are guaranteed to blow up unless
> the function in question is guaranteed to not terminate untill all
> threads are done with the data. What is the property pointer being
> initialized/set to?
>
> If it's dynamically allocated you should not have a problem.
>
> And I don't see how static vs. dynamic linking of libraries should
> matter, but perhaps I am overlooking something.

I don't get that either, should not have worked either way as far as I 
can tell.

-Mike