I think this will not matter. Systems which have sigqueue() must have sched_yield(), or they do not conform to POSIX, in any reasonable way.
Olga On Wed, Aug 21, 2013 at 5:36 PM, Glenn Fowler <[email protected]> wrote: > > sched_yield() is iffe'd > on systems that don't have it calls ast::tvsleep() => nanosleep() > > On Wed, 21 Aug 2013 17:21:29 +0200 =?KOI8-R?B?z8zYx8Egy9LZ1sHOz9fTy8HR?= > wrote: >> Does asoyield() call sched_yield()? The reason for sched_yield() is >> that the kernel scheduler is aware that the process is spinning, at >> the first use of scheld_yield(). For most kernels this sets a flag >> internally, so priority adjustments for fast, repeated sched_yield() >> usage happens immediately - which avoids that the kernel has to use >> statistics for cpu hogging processes instead - which are wrong in this >> case. Use of nanosleep() or similar apis MUST be avoided, at all cost, >> because the kernel will see this as sign, that the process is doing >> important stuff and has to be put on top of the scheduler queue each >> time the time out expires. This makes spin locks implemented via >> nanosleep() so bad, they just hog the cpu, at all costs, to the >> *severe* (unfair!!) disadvantage of all other processes. > >> Olga > >> On Wed, Aug 21, 2013 at 5:12 PM, Glenn Fowler <[email protected]> wrote: >> > >> > in ast call asoyield() for sched_yield() >> > >> > On Wed, 21 Aug 2013 16:58:40 +0200 =?KOI8-R?B?z8zYx8Egy9LZ1sHOz9fTy8HR?= >> > wrote: >> >> David, about 2., the code should *NOT* use sleep() or nanosleep() to >> >> wait after EAGAIN or you risk *DRAMATIC* priority inversion problems. >> >> I have experimented with this and EAGAIN can happen 2000, 200, 20, or >> >> just 2 times, or 0 times. >> >> The best solution we found is just to call sched_yield() and let the >> >> process spin. This will not affect system performance as the code >> >> walked in userland is very very small, and sched_yield() will >> >> guarantee that the kernel will only give CPU time if the scheduler >> >> queue cycles. At the same time, if sched_yield() is used (not >> >> nanosleep()!!!!!), the scheduler will give less and less priority to >> >> the spinning process. I tested this on Solaris, Linux, Illumos, >> >> FreeBSD and OSX. >> > >> >> Olga >> > >> >> On Wed, Aug 21, 2013 at 4:09 PM, David Korn <[email protected]> wrote: >> >> > cc: [email protected] >> >> > Subject: Re: Re: [ast-developers] [patch] kill(1) |sigqueue()| >> >> > fixes+|EAGAIN| handling etc. ... / was: Re: |sigqueue()| >> >> > fixes+|EAGAIN| handling etc. ... >> >> > -------- >> >> > >> >> >> Attached (as "astksh20130814_sigqueuerepeat002.diff.txt") is a patch >> >> >> which fixes (some of) the issues listed above... >> >> > >> >> > >> >> > I read over Rolands patch and while it contains useful ideas, I have >> >> > some problems with it. >> >> > >> >> > Let me go over them piece by piece. >> >> > >> >> > 1. Add -Q to pass addresses. >> >> > Currently the shell has no way of utilizing an address so there >> >> > is no present need. Currently, the value field models the >> >> > C standard and treats value as a union. However, it could treat >> >> > the field as an integer choosing the large of void* and int as >> >> > the size and pass the value that way. I would add a typedef >> >> > for this type. It would be an integral type rather than a >> >> > union. >> >> > A user could do kill -q $((0x4000abc)) or just kill -q >> >> > 0x4000abc to >> >> > send a pointer since optget will convert to an integer. >> >> > Programs could format the value as an address or as an int. >> >> > I think that this needs more discussion before adding -Q. >> >> > Commands already have too many options so I am reluctant to >> >> > add an option unless necessary. >> >> > >> >> > 2. Add -R to handle EAGAIN >> >> > I don't think that this is needed. EAGAIN should be handled >> >> > as it is with fork with an exponential back-off algorithm that >> >> > times out after around 30 seconds. EINTR will cause a retry >> >> > unless trapnote has pending trap or signal to process in which >> >> > case kill will fail. >> >> > >> >> > 3. Add -C to not send SIGCONT when sending a signal. I don't >> >> > see why you would want to send a signal to a stopped process >> >> > and not have it react. I believe that C-shell (the originator >> >> > of job control) always sent SIGCONT. If there is a need for >> >> > this, I could be convinced. >> >> > >> >> > Let me know what you think. >> >> > >> >> > David Korn >> >> > [email protected] >> >> > _______________________________________________ >> >> > ast-developers mailing list >> >> > [email protected] >> >> > http://lists.research.att.com/mailman/listinfo/ast-developers >> > >> >> -- >> >> , _ _ , >> >> { \/`o;====- Olga Kryzhanovska -====;o`\/ } >> >> .----'-/`-/ [email protected] \-`\-'----. >> >> `'-..-| / http://twitter.com/fleyta \ |-..-'` >> >> /\/\ Solaris/BSD//C/C++ programmer /\/\ >> >> `--` `--` >> > > >> -- >> , _ _ , >> { \/`o;====- Olga Kryzhanovska -====;o`\/ } >> .----'-/`-/ [email protected] \-`\-'----. >> `'-..-| / http://twitter.com/fleyta \ |-..-'` >> /\/\ Solaris/BSD//C/C++ programmer /\/\ >> `--` `--` > -- , _ _ , { \/`o;====- Olga Kryzhanovska -====;o`\/ } .----'-/`-/ [email protected] \-`\-'----. `'-..-| / http://twitter.com/fleyta \ |-..-'` /\/\ Solaris/BSD//C/C++ programmer /\/\ `--` `--` _______________________________________________ ast-developers mailing list [email protected] http://lists.research.att.com/mailman/listinfo/ast-developers
