Re: Making IOExitThread safe

So, I have a question about IOExitThread. I have a little driver for a
debug serial port that used use cdevsw on Panther, but is now rewritten
as a subclass of IOSerialStreamSync for Tiger. It uses one extra thread
to take pop data off of the TX queue and push it to the actual hardware
(the data for the RX queue arrives via interrupts). So, I create the
thread in my driver's start() routine and send it a signal to ask it to
die in my stop() routine. Is there any way that I can verify in my
stop() routine that the thread has truly died before returning? I
already do a hand-shake where I set a flag and to wake up the thread and
then in stop() I sleep until the thread wakes up, notices the flag is
set, and then clears it, drops its command gate and calls
IOExitThread(). My concern is that in theory, as soon as it signals the
thread in stop() and drops the command gate, the thread in stop() could
resume and return to its caller, and that depending on Murhpy's Law type
scheduling, the KEXT could be unloaded before the TX thread actually
gets a chance to call IOExitThread(), and thus when that thread is
finally resumed it would get a fault when it tried to execute code in
the function that calls IOExitThread().

In FreeBSD I changed the kernel thread exit function (kthread_exit()) to
do an extra wakeup on the proc pointer for the kthread in question to
allow callers to know when a thread that has been requested to die has
truly exited their module's code section so that it is safe to continue
a module unload operation. Is there anything similar that I can do with
an IOThread? Does I/O Kit do some extra magic with IOThreads to keep
track of this for me so that I don't have to handle this race?

Do you really need another thread to do work on, or do you just need a thread to do work on? If you don't care which thread and you don't need to do things in a synchronous fashion, you can simply create your own IOEventSource subclass and use the signalWorkAvailable()/checkForWork() paradigm. Attach the event source to the workloop, enabled it, and when you need to do stuff, call signalWorkAvailable().

-- Chris

------------------

6 Infinite Loop

M/S 306-2MS

Cupertino CA 95014

phone: (408) 974-4033

fax: (408) 862-7577

email: email@hidden

References:
	>Making IOExitThread safe (From: "Baldwin, John" <email@hidden>)