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
_______________________________________________
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
