From owner-freebsd-hackers@FreeBSD.ORG Wed Mar 16 21:54:52 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4071E16A4CE for ; Wed, 16 Mar 2005 21:54:52 +0000 (GMT) Received: from vms046pub.verizon.net (vms046pub.verizon.net [206.46.252.46]) by mx1.FreeBSD.org (Postfix) with ESMTP id CFCD443D2D for ; Wed, 16 Mar 2005 21:54:51 +0000 (GMT) (envelope-from ringworm01@gmail.com) Received: from ringworm.mechee.com ([4.27.46.32])0.04 <0IDG00LJ4SVEJB21@vms046.mailsrvcs.net> for freebsd-hackers@freebsd.org; Wed, 16 Mar 2005 15:54:51 -0600 (CST) Received: by ringworm.mechee.com (Postfix, from userid 1001) id 6E8682CE740; Wed, 16 Mar 2005 13:54:49 -0800 (PST) Date: Wed, 16 Mar 2005 13:54:47 -0800 From: "Michael C. Shultz" In-reply-to: <20050316214014.GA88231@scode-whitestar.mine.nu> To: Peter Schuller Message-id: <200503161354.48223.ringworm01@gmail.com> MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7bit Content-disposition: inline References: <200503151228.17719.ringworm01@gmail.com> <20050316214014.GA88231@scode-whitestar.mine.nu> User-Agent: KMail/1.7.2 cc: freebsd-hackers@freebsd.org cc: Zera William Holladay Subject: Re: threads question X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Mar 2005 21:54:52 -0000 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