Jim Magee wrote: Wally Crooze wrote: Continuing on from the locking and synchronization primitives... I have the need to be able to associate particular information with a thread which is specific to my kext project. In other OSes an interface is provided to allow information stored which doesn't effect the control of the thread. I found the following interfaces which set/retrieve thread_t->saved.misc: extern void thread_set_cont_arg(int); extern int thread_get_cont_arg(void); These aren't used anywhere in xnu, but thread_t->saved is a union and is used for other information. Are these interfaces expected to be used for miscellaneous thread information within my own code? Also, can I treat this int as a void* ? You can only use this to save information while you are causing the thread to block. Some such blocks can occur at continuation points (where the kernel stack is thrown away). These are the continuation arguments that you can use to build context back up when the thread resumes. If you aren't blocking the thread, you can't claim ownership of these fields. Does this mean that I can expect that at no time the thread is in my code these fields will be in use? And that they wont be effected in any blocking (i.e. locking/synchronisation) calls? Unfornately neither the Kernel Programming guide and Threading Architecture Technotes describe a method of associating an information context to the thread. That's because there isn't any such mechanism today. We are looking at providing a generalized version of thread-local-data for the kernel environment. But we don't have anything like that now. I guess that I must use a lookup table mechanism on the thread to retrieve my data. This will certainly effect the performance. Is there a reason why a generic pointer for use within kexts (or drivers) isn't available? An example for this use is part of my sema implementation requires to store whether the thread was woken normally or by an (software) interrupt from my code. This is a situation where use of the cont_arg mechanism would be appropriate. But you might want to use the wait_result value for this indication (depending upon what sleep/wakeup mechanism you are using). Remember that unless you block threads as "uninterruptible", the signal/Mach thread_abort mechanisms may do the interruptions without your wakeup code ever getting involved. You must deal with those cases. They will result in a wait_result of THREAD_INTERRUPTED. If you want to "poke at" a thread without making it look like a signal, the THREAD_RESTART wait_result is commonly used. Is there an interface to "interrupt" a semaphore as opposed to waking it? Or is it easier to mimic this in software with my own flags? -- Wally Crooze +-------------------------------------------------------+ | ,-_|\ Wally Crooze <wallycrooze@pobox.com> | | / \ | | \_,-._/ | | v | +-------------------------------------------------------+ _______________________________________________ darwin-kernel mailing list | darwin-kernel@lists.apple.com Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/darwin-kernel Do not post admin requests to the list. They will be ignored.