From: Jens Thoms Toerring on
In comp.unix.programmer Jasen Betts <jasen(a)xnet.co.nz> wrote:
> select() prefers the lowest numbered file descriptor it's asked to
> test/watch so that should be easy to arrange,

Just curious: in what sense does select() "prefer" lower numbered
file descriptors?
Regards, Jens
--
\ Jens Thoms Toerring ___ jt(a)toerring.de
\__________________________ http://toerring.de
From: Peter Olcott on
If it runs at all it ruins my cache spatial locality of
reference and makes the other process at least ten-fold
slower, that is why I want to make these jobs sequential.

"David Schwartz" <davids(a)webmaster.com> wrote in message
news:a0c89ef2-0206-46fd-bc8c-9998a3ebdcee(a)z7g2000yqb.googlegroups.com...
On Apr 6, 7:31 pm, "Peter Olcott" <NoS...(a)OCR4Screen.com>
wrote:

> Since I will only have one core initially, I want to have
> the one process somehow put the other process to sleep
> when
> there are any items in the high priority queue. Can
> Linux/Unix do this easily?

Set the priority significantly higher.

DS


From: Peter Olcott on

"Phil Carmody" <thefatphil_demunged(a)yahoo.co.uk> wrote in
message news:87k4sjhke4.fsf(a)kilospaz.fatphil.org...
> "Peter Olcott" <NoSpam(a)OCR4Screen.com> writes:
>> "Rainer Weikusat" <rweikusat(a)mssgmbh.com> wrote in
>> message
>> news:87d3ycnwcl.fsf(a)fever.mssgmbh.com...
>>> "Peter Olcott" <NoSpam(a)OCR4Screen.com> writes:
>>>> "Scott Lurndal" <scott(a)slp53.sl.home>: wrote in message
>>>>> "Peter Olcott" <NoSpam(a)OCR4Screen.com> writes:
>>>
>>> [...]
>>>
>>>>>>I am only focusing on the design of the preemptive
>>>>>>scheduling now.
>>>>>>Also the initial hardware will only have a single core
>>>>>>with
>>>>>>hyperthreading.
>>>>>>
>>>>>
>>>>> You are making this far more complicated than
>>>>> necessary.
>>>>> Have fun.
>>>>>
>>>>> scott
>>>>
>>>> So then do you have a simple way to implement
>>>> preemptive
>>>> scheduling?
>>>
>>> If you are convinced that this is the solution to your
>>> problem, the
>>> kernel already provides exactly that. You just have to
>>> use
>>> the
>>> existing facilities.
>>
>> So the OS will put a thread to sleep, saving its
>> multi-megabyte state upon a process triggered event?
>
> What, *precisely*, do you mean by "saving" the state,
> and why are you so worried by that?
>
>> I would save the state with a simple change of the
>> integer
>> subscript into an array of each threads data. Could the
>> OS
>> be told that this is what is needed?
>
> In which case you have to simultaniously maintain the
> multi-megabyte
> state of _all_ of the "thread data".

David has mostly convinced me that my 3.5 minute job is best
off as its own process. The only issue is that the minimum
sleep period seems to be one second, I could really use it
to be 100 ms. I might have to build my own sleep system for
this process.

>
> You're frightened of ghosts.
>
> Phil
> --
> I find the easiest thing to do is to k/f myself and just
> troll away
> -- David Melville on r.a.s.f1


From: Peter Olcott on
"Jasen Betts" <jasen(a)xnet.co.nz> wrote in message
news:hphr56$qe0$1(a)reversiblemaps.ath.cx...
> On 2010-04-04, Peter Olcott <NoSpam(a)OCR4Screen.com> wrote:
>>
>> So it is in an infinite loop eating up all of the CPU
>> time
>> only when there are no requests to process?
>
> no it's a read() that doesn't return or a select() that
> times out
> while there are no requests inbound.

Great thanks.

>
> as soon as something arives and the kernel scheduler gets
> around to
> activiating your progcess (immediately if the cpu is not
> busy)
> the read() will return or select indiocate an non-blocking
> file
> descriptor.
>
>> I don't think
>> that I want this either because I will have two
>> priorities
>> of requests. If there are no high priority requests I
>> want
>> it to begin working on the low priority requests.
>
> select() prefers the lowest numbered file descriptor it's
> asked to
> test/watch so that should be easy to arrange,
>
>
>
> --- news://freenews.netfront.net/ - complaints:
> news(a)netfront.net ---


From: Jens Thoms Toerring on
In comp.unix.programmer Peter Olcott <NoSpam(a)ocr4screen.com> wrote:
> David has mostly convinced me that my 3.5 minute job is best
> off as its own process. The only issue is that the minimum
> sleep period seems to be one second, I could really use it
> to be 100 ms. I might have to build my own sleep system for
> this process.

For the sleep() function that's correct. For shorter sleep
periods use nanosleep(), that should give you a resolution
of at least 10 ms.
Regards, Jens

PS: Please stop crossposting this to linux.development.system,
that group is about "Linux kernels, device drivers, modules"
and thus the whole stuff discussed here is off-topic over
there.
--
\ Jens Thoms Toerring ___ jt(a)toerring.de
\__________________________ http://toerring.de