On Friday, June 21, 2002, at 12:50 PM, Jonathan Hess wrote: How would one receive notification (signal or otherwise) that the current thread is about to be or was just swapped out and that the current thread is about to be or was just swapped back in? By "just about to be swapped out" I assume you mean "just about to lose control/ownership of a processor." If so, the answer is "no way, no how." That is about the most time critical path in the system. We can't put notifications/callbacks in there. I guess if you wanted to waste your own cycles on processing a "just got control back" kind of notification, that would be a different thing. But I don't think it would be very useful, and there is no such mechanism today. With present compilers and the PPC RTC register "active" profilers are a real possibility. But, to make them robust on a preemptive multi-cpu OS the question above must be resolved. I've thought about instrumenting semaphore and mutex abstractions and finding and instrumenting the time slice expired signal. To be generally useful, all calls that would likely block the current thread (read, write, accept, glFlush, etc, etc) would have to be instrumented. But these all just seem like problematic hacks that avoid finding the real solution. Is there an exposed relatively hi-level way in the shipping kernel to do this? If not, any pointers on where to look in the kernel? No real-time notifications. But there is a trace mechanism that gives you the raw information to post-process. That's the same data that feeds the sc_usage, fs_usage, and latency performance utility tools. --Jim _______________________________________________ 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.