September 2007 - Darwin-kernel

Re: Yielding the processor in a kext?
by Jonas Maebe 07 Sep '07

07 Sep '07

site_archiver(a)lists.apple.com Delivered-To: darwin-kernel(a)lists.apple.com On 07 Sep 2007, at 19:22, Régis Duchesne wrote: I have perfect control on Windows where Sleep(0) is documented to do exactly what I want. I have perfect control on Linux where cond_resched() is documented to do exactly what I want. I'm trying to have perfect control on Mac OS by finding an API that is documented to do exactly what I want :) You could have a look at to which kernel api sched_yield() is connected. Jonas _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-kernel mailing list (Darwin-kernel(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-kernel/site_archiver%40lists.… This email sent to site_archiver(a)lists.apple.com

1 0

Re: Yielding the processor in a kext?
by Régis Duchesne 07 Sep '07

07 Sep '07

site_archiver(a)lists.apple.com Delivered-To: darwin-kernel(a)lists.apple.com User-agent: Icedove 1.5.0.9 (X11/20061220) Michael, > The problem here is that you are conflating "thread" with "work". > > Ideally you would parcel your work out in well-ordered units, and > schedule those units to threads in such a fashion that progress happens > with the desired balance. That is great in an ideal world where you write the code that the threads execute. But we don't live in an ideal world: in my case each thread is like a black box: I control the initial input to these threads, but then they go do their heavy computation, and just report progress. What they do precisely to perform their computation is unknown to me. All I know is that if I make them progress at the same rate, whatever they compute will be computed faster overall (and more accurately). >> We are wondering which API can be used to do that. Would an IOSleep(0) >> (which is the way you do it on Windows) work or will it just be ignored? > > You don't want to do this, on either platform. You have no control over > what "slow it down" actually means, and you aren't communicating what > you really want to the scheduler. I have perfect control on Windows where Sleep(0) is documented to do exactly what I want. I have perfect control on Linux where cond_resched() is documented to do exactly what I want. I'm trying to have perfect control on Mac OS by finding an API that is documented to do exactly what I want :) Thanks, -- hpreg _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-kernel mailing list (Darwin-kernel(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-kernel/site_archiver%40lists.… This email sent to site_archiver(a)lists.apple.com

1 0

Re: Yielding the processor in a kext?
by Régis Duchesne 07 Sep '07

07 Sep '07

site_archiver(a)lists.apple.com Delivered-To: darwin-kernel(a)lists.apple.com User-agent: Icedove 1.5.0.9 (X11/20061220) Michael, > 1) When a long-running task is being performed at an inappropriate > priority, and it might be "nice" to let other threads have the CPU. > > In this case, I argue that the task should simply be moved to > another thread that runs at an appropriate priority. So let's say I realize that one of my threads is too far ahead of the others in its computation. I want to slow it down, so I'll reduce its priority. Now imagine that 2 different users start 2 different instances of the app: o User A starts the app with 2 threads TA1 and TA2, and this scenario occurs, TA1 is way ahead of TA2, so TA1 lowers is priority. o User B starts the app with only 1 thread TB. At this point, user A loses: TA1 will almost never be scheduled anymore, because TB will always have a higher priority. I really want to lower the priority of my thread _within_ its task (because the scheduling of that thread relative to the other in the same task is a decision that can be best made by my app). But the APIs that I find only allow me to do it system-wide. So as a workaround, I want a way to yield the processor, i.e. go at the end of the scheduling queue but with the exact same priority. Thanks, -- hpreg _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-kernel mailing list (Darwin-kernel(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-kernel/site_archiver%40lists.… This email sent to site_archiver(a)lists.apple.com

1 0

Re: Yielding the processor in a kext?
by Régis Duchesne 07 Sep '07

07 Sep '07

site_archiver(a)lists.apple.com Delivered-To: darwin-kernel(a)lists.apple.com User-agent: Icedove 1.5.0.9 (X11/20061220) Folks, Michael Smith wrote: > It's not your business to make scheduling > decisions; don't even try. That is just not true. In the example I gave in my previous email, I show that sometimes, the application knows better than the OS how things must be scheduled. It does not matter how much progress all my threads make compared to the rest of the system, but it does matter how much progress they make relative to each other. In other words, I'm trying to write my own little scheduler (just for all the threads within my task), on top (not instead of) the xnu system-wide scheduler. I'm the only one who can do that because xnu obviously doesn't know the specifics of my application. Terry Lambert wrote: > You block on the mutex held by the other thread Well that does not work in my case either: as I explained, I don't want to stop the thread that is too far ahead in the computation. I just want to slow it down. So blocking is not an option. I want to hint the scheduler that "hey, you made me run, but at the app level I know that it is better if I do nothing at this moment, so I would like to voluntarily relinquish my time slice." Thanks, -- hpreg _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-kernel mailing list (Darwin-kernel(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-kernel/site_archiver%40lists.… This email sent to site_archiver(a)lists.apple.com

1 0

Re: Yielding the processor in a kext?
by Michael Smith 07 Sep '07

07 Sep '07

site_archiver(a)lists.apple.com Delivered-To: darwin-kernel(a)lists.apple.com On Sep 7, 2007, at 1:08 AM, Anton Altaparmakov wrote: I understand that by default threads executing in the kernel are pre-emptable, but sometimes I would like the current thread to explicitly give the scheduler a chance to schedule another thread, before the current thread's timeslice has elapsed. I'm looking for something similar to cond_resched() on Linux. You're right, it is. You should, instead, either: Note also that you confused my original point with a different one. = Mike _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-kernel mailing list (Darwin-kernel(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-kernel/site_archiver%40lists.… \On 7 Sep 2007, at 03:55, Michael Smith wrote: On Sep 6, 2007, at 5:03 PM, Régis Duchesne wrote: Is there a way to make the current thread yield the processor in a kext? Not in the fashion you describe. If you have work, do it. If the scheduler has more important work that has to be done, it will take the CPU away from your thread. But for example from a file system kext we don't know what priority the thread is and we don't own the thread either so we should not be messing with priorities... On the contrary. As a filesystem, if you need to perform a lengthy task, the onus is on you to ensure that you do it on a thread with an appropriate priority. If this means kicking off another thread, so be it. And what if we have work to do but can't do it because we need another thread to do work first? It is stupid to hang onto our time slice in at this point... If you have work to do that you can't do because some other thread has work to do, you must necessarily have a synchronisation object that is shared between you and the other thread. Thus, you will block on said synchronisation object. This is a truly fundamental threaded programming metaphor, and the only way to avoid priority inversion. If, as you are implicitly suggesting, a high priority consumer thread were to spin polling and yielding, there is no guarantee that the lower priority worker thread would ever get the task done. The only reason to want to do this is if you are performing a long- running low priority task on the wrong (high-priority) thread. Don't do that. Do the work on a thread whose priority reflects the true priority of the task. It's not your business to make scheduling decisions; don't even try. Your view is too limited. This is not true at all. I will give you a concrete example of when I would like to yield the CPU from my file system kext: I need to take a lock but I can't do it safely because of holding other locks so I do a try-lock. The try-lock fails so I have to drop my locks and try again. It is totally brain damaged to try again immediately. It would be far more sensible to yield the CPU to give the other process holding my lock to finish its work and release it and when the scheduler next gets to my process for me to try again and if I fail again to yield again, etc... And trying again immediately is actually MUCH worse than the fact that CPU is just being burned unnecessarily because the other process might be trying to take the lock I just dropped so if I take it again immediately the chances of the other process taking that lock successfully and hence making progress thus releasing both locks so my process can make progress are close to zero at this point! )-: I would argue that you're making several erroneous assumptions here. The first is that it's a good idea for you to ever hold more than one lock in kernel code. The second is that you should permit the acquisition of locks in arbitrary order. Both are bad programming practice; the latter is in fact *awful* practice. Thirdly, you are assuming that the thread holding the lock(s) you want will actually run as a consequence of your yielding; implying that "yield" has semantics beyond "terminate my quantum early". And another example: In a critical path when a memory allocation fails, I want to yield the CPU and try again later when the system hopefully has more memory available as failing the allocation is a disaster for file system consistency at this point. At the moment I just do it in a busy loop trying again and again and again till the scheduler decides to reschedule me. That's got to be totally insane... )-: a) Fail the operation with a resource shortage error. b) Use one of the memory allocation primitives that knows how to wait intelligently for memory to become available. I would very much like to know how I can tell the scheduler "I am done, hand CPU to someone else now"... Tell it under what criteria you will be able to run again; block on a synchronisation primitive, or take advantage of infrastructure that will do so on your behalf. There are two reasons that people think that yield() might be a good idea in kernel code. 1) When a long-running task is being performed at an inappropriate priority, and it might be "nice" to let other threads have the CPU. In this case, I argue that the task should simply be moved to another thread that runs at an appropriate priority. 2) When there is a priority inversion (thread, lock, etc.) and the caller thinks that a lower-priority thread needs to run in order for the current thread to make progress. In this case, I argue that polling (what use of yield devolves to) is inferior to well-designed code and use of blocking primitives. This email sent to site_archiver(a)lists.apple.com

1 0

Re: Yielding the processor in a kext?
by Régis Duchesne 07 Sep '07

07 Sep '07

site_archiver(a)lists.apple.com Delivered-To: darwin-kernel(a)lists.apple.com User-agent: Icedove 1.5.0.9 (X11/20061220) Garth, > As you probably know, there's the I/O Kit world with its way of doing > things, then there's the rest of the kernel. Which are you asking about? Sorry I might be using the wrong terminology. I'm asking about a way to do it from a kext (as opposed to the core xnu code). Whether that kext is IOKit-style or BSD-style does not matter to me. I'll take anything you give me :) > What's going on in your kext when you want to yield? We manage a bunch of (userland) threads that do some heavy computation (very similar to finite element analysis). For some reason that I'm not going to detail here, this management happens in a kext. Our goal is to make sure that none of these threads computes much faster than the others. That is, the more consistent the rate of progress across all these threads, the better the accuracy of the result of the computation. The xnu scheduler is of course free to schedule these threads as it wants (no CPU affinity API is available to userland or kexts), and it knows nothing about the specifics of our application. So our solution is to periodically measure how much progress has been accomplished by these threads, and if one of them is too far ahead of the others, we don't want to stop it but we want to slow it down compared to the other threads. To slow it down, we would like to yield the processor, i.e. just deschedule the current thread, which is at the beginning of the scheduling queue for its priority, and move it at the end of that queue. We are wondering which API can be used to do that. Would an IOSleep(0) (which is the way you do it on Windows) work or will it just be ignored? Thanks, -- hpreg _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-kernel mailing list (Darwin-kernel(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-kernel/site_archiver%40lists.… This email sent to site_archiver(a)lists.apple.com

1 0

Re: Yielding the processor in a kext?
by mm w 07 Sep '07

07 Sep '07

site_archiver(a)lists.apple.com Delivered-To: darwin-kernel(a)lists.apple.com Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=InoZSstj5ZSSvMheGQjVhylnlx0m0Mplarmh/YQ898c=; b=QUipiGHFQ60sUERAPybvIj4QNCju/DnLd2iPqjmKj2kiUq/vqsqexZnMpYIRpww2bu1OY7HZsfuEZ/lS8kGM1YrPskwRiX3jvQzhPX6tkGs2160sx8V00/FyGEvbLOxk/8rEpGwfozMFLd5+swFOEREIuS0eu5bbW1uplddbZUI= Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=sNnHhbAqAZqfh6WxAWBLPwGIO4oUjfYEFZvGaddzVbNVRZPV4N2FUNvdMDho0yq3B5sQlbnDguLwphsKHoXijdToXcYwWsPxKuWidQx1V1sXBQcgYJhzVqy/gyk0sPy5Eg6Sh3yCZ2iGPSkmblXnh2S8zR8dUt60oFEu50IOXO4= it seems that you want to delay execution which execution (main thread) ? you can use timer, maybe IOTimerEventSource.h or IODelay, maybe mach/task.h and osfmk/mach/semaphore.h are your friends - mm w cheers! On 9/7/07, Régis Duchesne <hpreg(a)vmware.com> wrote: > Folks, > > Is there a way to make the current thread yield the processor in a kext? > > I understand that by default threads executing in the kernel are > pre-emptable, but sometimes I would like the current thread to > explicitly give the scheduler a chance to schedule another thread, > before the current thread's timeslice has elapsed. I'm looking for > something similar to cond_resched() on Linux. > > Thanks, > -- > hpreg > _______________________________________________ > Do not post admin requests to the list. They will be ignored. > Darwin-kernel mailing list (Darwin-kernel(a)lists.apple.com) > Help/Unsubscribe/Update your Subscription: > http://lists.apple.com/mailman/options/darwin-kernel/openspecies%40gmail.com > > This email sent to openspecies(a)gmail.com > -- http://openspecies.googlepages.com/gpgkey.txt _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-kernel mailing list (Darwin-kernel(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-kernel/site_archiver%40lists.… This email sent to site_archiver(a)lists.apple.com

1 0

Re: Yielding the processor in a kext?
by Anton Altaparmakov 07 Sep '07

07 Sep '07

site_archiver(a)lists.apple.com Delivered-To: darwin-kernel(a)lists.apple.com Hi, Thanks for the suggestions. Best regards, Anton -- Anton Altaparmakov <aia21 at cam.ac.uk> (replace at with @) Unix Support, Computing Service, University of Cambridge, CB2 3QH, UK Linux NTFS maintainer, http://www.linux-ntfs.org/ _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-kernel mailing list (Darwin-kernel(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-kernel/site_archiver%40lists.… On 7 Sep 2007, at 11:06, Terry Lambert wrote: On Sep 7, 2007, at 1:08 AM, Anton Altaparmakov wrote: On 7 Sep 2007, at 03:55, Michael Smith wrote: On Sep 6, 2007, at 5:03 PM, Régis Duchesne wrote: Is there a way to make the current thread yield the processor in a kext? Not in the fashion you describe. If you have work, do it. If the scheduler has more important work that has to be done, it will take the CPU away from your thread. But for example from a file system kext we don't know what priority the thread is and we don't own the thread either so we should not be messing with priorities... And what if we have work to do but can't do it because we need another thread to do work first? It is stupid to hang onto our time slice in at this point... You block on the mutex held by the other thread that you know you need to wait for because it holds the mutex. Then the scheduler does it's normal priority lending trick, and you implicitly yield anyway, and the other thread gets the priority boost necessary to get its work done ASAP and get you unblocked ASAP. Yes that of course works as long as you don't get an AB-BA deadlock as in my example... The only reason to want to do this is if you are performing a long-running low priority task on the wrong (high-priority) thread. Don't do that. Do the work on a thread whose priority reflects the true priority of the task. It's not your business to make scheduling decisions; don't even try. Your view is too limited. This is not true at all. I will give you a concrete example of when I would like to yield the CPU from my file system kext: I need to take a lock but I can't do it safely because of holding other locks so I do a try-lock. The try-lock fails so I have to drop my locks and try again. It is totally brain damaged to try again immediately. It would be far more sensible to yield the CPU to give the other process holding my lock to finish its work and release it and when the scheduler next gets to my process for me to try again and if I fail again to yield again, etc... And trying again immediately is actually MUCH worse than the fact that CPU is just being burned unnecessarily because the other process might be trying to take the lock I just dropped so if I take it again immediately the chances of the other process taking that lock successfully and hence making progress thus releasing both locks so my process can make progress are close to zero at this point! )-: Except that the scheduler is going to raise your priority until it eclipses everything else because you constantly fail to utilize your full quantum, yet are constantly runnable. I expect that you would be unable to actually rool your state back forward immediately, though, since, having backed out your state, the other thread is able to make progress, and you won't be able to immediately acquire your mutex any more. But assuming instead that you aren't trying to fight a lock order inversion with a scheduler hack here, the answer would be "call IOSleep or consider refactoring your code so that this doesn't become an issue in the first place". Like maybe use a deadicated worker thread and an IOWorkQueue. And another example: In a critical path when a memory allocation fails, I want to yield the CPU and try again later when the system hopefully has more memory available as failing the allocation is a disaster for file system consistency at this point. At the moment I just do it in a busy loop trying again and again and again till the scheduler decides to reschedule me. That's got to be totally insane... )-: Set the M_WAIT flag so the allocation blocks until it can be satisfied or the heat death of the universe, whichever comes first. How do you do that with OSMalloc()? Is there some way to maybe set this in the tag supplied to OSMalloc() or something? Or are you suggesting I should be using a different allocator altogether? I have been told that OSMalloc() is the only allocator I should be using from a file system kext (that comes straight from the guys working on the memory allocators). I would very much like to know how I can tell the scheduler "I am done, hand CPU to someone else now"... Generally, by blocking on something that, when there is work for you to do, will wake you up (or by returning to your caller, if you are on a user space thread context instead of your own worker thread). The kernel either lets you run, preempts you, because you are interruptible, or lets you block waiting for a resource ("more work to do" is a resource). This email sent to site_archiver(a)lists.apple.com

1 0

Re: Yielding the processor in a kext?
by Terry Lambert 07 Sep '07

07 Sep '07

site_archiver(a)lists.apple.com Delivered-To: darwin-kernel(a)lists.apple.com -- Terry _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-kernel mailing list (Darwin-kernel(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-kernel/site_archiver%40lists.… On Sep 7, 2007, at 1:08 AM, Anton Altaparmakov wrote: On 7 Sep 2007, at 03:55, Michael Smith wrote: On Sep 6, 2007, at 5:03 PM, Régis Duchesne wrote: Is there a way to make the current thread yield the processor in a kext? Not in the fashion you describe. If you have work, do it. If the scheduler has more important work that has to be done, it will take the CPU away from your thread. But for example from a file system kext we don't know what priority the thread is and we don't own the thread either so we should not be messing with priorities... And what if we have work to do but can't do it because we need another thread to do work first? It is stupid to hang onto our time slice in at this point... You block on the mutex held by the other thread that you know you need to wait for because it holds the mutex. Then the scheduler does it's normal priority lending trick, and you implicitly yield anyway, and the other thread gets the priority boost necessary to get its work done ASAP and get you unblocked ASAP. The only reason to want to do this is if you are performing a long- running low priority task on the wrong (high-priority) thread. Don't do that. Do the work on a thread whose priority reflects the true priority of the task. It's not your business to make scheduling decisions; don't even try. Your view is too limited. This is not true at all. I will give you a concrete example of when I would like to yield the CPU from my file system kext: I need to take a lock but I can't do it safely because of holding other locks so I do a try-lock. The try-lock fails so I have to drop my locks and try again. It is totally brain damaged to try again immediately. It would be far more sensible to yield the CPU to give the other process holding my lock to finish its work and release it and when the scheduler next gets to my process for me to try again and if I fail again to yield again, etc... And trying again immediately is actually MUCH worse than the fact that CPU is just being burned unnecessarily because the other process might be trying to take the lock I just dropped so if I take it again immediately the chances of the other process taking that lock successfully and hence making progress thus releasing both locks so my process can make progress are close to zero at this point! )-: Except that the scheduler is going to raise your priority until it eclipses everything else because you constantly fail to utilize your full quantum, yet are constantly runnable. I expect that you would be unable to actually rool your state back forward immediately, though, since, having backed out your state, the other thread is able to make progress, and you won't be able to immediately acquire your mutex any more. But assuming instead that you aren't trying to fight a lock order inversion with a scheduler hack here, the answer would be "call IOSleep or consider refactoring your code so that this doesn't become an issue in the first place". Like maybe use a deadicated worker thread and an IOWorkQueue. And another example: In a critical path when a memory allocation fails, I want to yield the CPU and try again later when the system hopefully has more memory available as failing the allocation is a disaster for file system consistency at this point. At the moment I just do it in a busy loop trying again and again and again till the scheduler decides to reschedule me. That's got to be totally insane... )-: Set the M_WAIT flag so the allocation blocks until it can be satisfied or the heat death of the universe, whichever comes first. I would very much like to know how I can tell the scheduler "I am done, hand CPU to someone else now"... Generally, by blocking on something that, when there is work for you to do, will wake you up (or by returning to your caller, if you are on a user space thread context instead of your own worker thread). The kernel either lets you run, preempts you, because you are interruptible, or lets you block waiting for a resource ("more work to do" is a resource). This email sent to site_archiver(a)lists.apple.com

1 0

Re: Yielding the processor in a kext?
by Anton Altaparmakov 07 Sep '07

07 Sep '07

site_archiver(a)lists.apple.com Delivered-To: darwin-kernel(a)lists.apple.com Hi, I understand that by default threads executing in the kernel are pre-emptable, but sometimes I would like the current thread to explicitly give the scheduler a chance to schedule another thread, before the current thread's timeslice has elapsed. I'm looking for something similar to cond_resched() on Linux. Best regards, Anton -- Anton Altaparmakov <aia21 at cam.ac.uk> (replace at with @) Unix Support, Computing Service, University of Cambridge, CB2 3QH, UK Linux NTFS maintainer, http://www.linux-ntfs.org/ _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-kernel mailing list (Darwin-kernel(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-kernel/site_archiver%40lists.… On 7 Sep 2007, at 03:55, Michael Smith wrote: On Sep 6, 2007, at 5:03 PM, Régis Duchesne wrote: Is there a way to make the current thread yield the processor in a kext? Not in the fashion you describe. If you have work, do it. If the scheduler has more important work that has to be done, it will take the CPU away from your thread. But for example from a file system kext we don't know what priority the thread is and we don't own the thread either so we should not be messing with priorities... And what if we have work to do but can't do it because we need another thread to do work first? It is stupid to hang onto our time slice in at this point... The only reason to want to do this is if you are performing a long- running low priority task on the wrong (high-priority) thread. Don't do that. Do the work on a thread whose priority reflects the true priority of the task. It's not your business to make scheduling decisions; don't even try. Your view is too limited. This is not true at all. I will give you a concrete example of when I would like to yield the CPU from my file system kext: I need to take a lock but I can't do it safely because of holding other locks so I do a try-lock. The try-lock fails so I have to drop my locks and try again. It is totally brain damaged to try again immediately. It would be far more sensible to yield the CPU to give the other process holding my lock to finish its work and release it and when the scheduler next gets to my process for me to try again and if I fail again to yield again, etc... And trying again immediately is actually MUCH worse than the fact that CPU is just being burned unnecessarily because the other process might be trying to take the lock I just dropped so if I take it again immediately the chances of the other process taking that lock successfully and hence making progress thus releasing both locks so my process can make progress are close to zero at this point! )-: And another example: In a critical path when a memory allocation fails, I want to yield the CPU and try again later when the system hopefully has more memory available as failing the allocation is a disaster for file system consistency at this point. At the moment I just do it in a busy loop trying again and again and again till the scheduler decides to reschedule me. That's got to be totally insane... )-: I would very much like to know how I can tell the scheduler "I am done, hand CPU to someone else now"... This email sent to site_archiver(a)lists.apple.com

1 0