Date: Sun, 18 May 1997 19:45:30 -0700 (MST) From: Terry Lambert <terry@lambert.org> To: deischen@iworks.InterWorks.org (Daniel M. Eischen) Cc: terry@lambert.org, freebsd-hackers@FreeBSD.ORG, jb@freebsd1.cimlogic.com.au Subject: Re: GNAT-pthreads integration bugs/questions Message-ID: <199705190245.TAA23268@phaeton.artisoft.com> In-Reply-To: <199705190010.TAA21397@iworks.InterWorks.org> from "Daniel M. Eischen" at May 18, 97 07:10:36 pm
next in thread | previous in thread | raw e-mail | index | archive | help
[ ... synchronization primitives ... ] > I was also looking at flock(). Use fcntl() advisory locking instead -- you will end up with more than one lock per file. 8-). > > > and the ability to create a key (pthread_key_create) that is specific > > > to each process - like taskVarAdd() in VxWorks :-) > > > > Why not call getpid()? > > I need to be able to bind a structure (pointer) to a process ID. I > could maintain a list of process ID/structure pointer pairs and then > search through the list based on process ID. The pthread_getspecific() > and pthread_setspecific do this based on the thread ID. The taskVarAdd() > in VxWorks is even nicer because it automatically swaps the task > variable for you whenever tasks are swapped - no need to call a get. Well, the heap is shared in the RFMEM case. I don't see why you could not implement it using a global counter, provided it only ever gets called once per process. You could use the counter value locally to index an array of these structs in the heap. Alternately, you could allocate the structure on the stack and pass it down (similar to David's suggestion), but this would imply some very fierce restrictions on where and when you could procedurally "start a new 'thread'". Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199705190245.TAA23268>