stop()+prun would freeze the whole process... I think he wants other threads to continue (possibly doing bad things) while the current thread is stopped. Some other thread might take the current thread's place when prun gets things moving again, but it seems an awfully expensive and roundabout way to achieve the effect.
Besides, this can't possibly be worse than raising a signal from dtrace... it should be possible to set some flag in the kthread and have appropriate code check it "soon," where "soon" usually means "before return to user space." Something similar to how how issig_forreal() checks the dtrace_signal flag, but I'm not a kernel expert to know whether there's a similarly convenient spot for inserting a scheduler decision. -- This message posted from opensolaris.org _______________________________________________ dtrace-discuss mailing list [email protected]
