Re: lug-bg: ps ax|grep sth

[George Danchev <danchev@xxxxxxxxx>]

On Tuesday 14 June 2005 13:59, Delian Krustev wrote:
> On Monday 13 June 2005 16:42, George Danchev wrote:
> > Мда, май не сме точни в това какво значи едновременно защото ядрото
> > отделя внимание на процесите в timeslices[0] нищо, че може да са и в
> > pipe. Значи ядрото много бързо пуска (RN) и приспива процесите (S)
> > (състоянията ги има описани в man ps) от двете страни на pipe-a с дискрет
> > най-малко а може и няколко един timeslice защото не са само те. Какво ще
> > стане ако ps приключи преди да е изтекъл неговия timeslice /много рядко
> > може да стане, но има и такъв шанс както се вижда и тогава в неговия
> > изход няма да има grep /
>
> Ще завърши процеса и изхода му ще бъде записан в буфера на pipe-a.
> grep ще чете, ще срещне EOF, и ще завърши и той.
>
> Това дали грепа ще се види самия себе си зависи от големината на буфера,
> количеството на изхода от ps, и read ordera на /proc който използва ps.

OK, съгласен. Но това което бях описал за ps | grep и имах на предвид в 
предното писмо, е 
(образно казано): 
<първи timeslice за ps>
вади какво ще вади, но няма да види grep защото още ядрото не му е отделило 
време за стартиране, не препълва PIPE_BUF буфера обаче и:
munmap()
exit_group(0)
....
</изтича timeslice>

<следва първи timeslice за grep>
който не вижда себе си в изхода на ps който е в буфера защото той се е 
изпълнил и exit-нал преди да го има този процес grep и за това няма как да го 
види. / е ако няма други процеси grep де, но ние се интересуваме от grep в 
другия край на тръбата /
</>

Това е много рядко разбира се. Обратно ако изпълнението на ps отнеме повече 
време тогава ядрото ще има възможност да отдели следващия /например/ 
timeslice за grep и когато даде пак  timeslice на ps вече той ще види този 
grep.

> Буфера се явява семафор, като напълването му не е необходимо и
> достатъчно условие за блокиране и разблокиране на съответните процеси. При
> забавяне от страна на writer-а примерно(изтичане на timeslice-a му),
> reader-a може да прочете частично запълнен буфер.
>
> >. Дали
> > ще бъде поставен в състояние RN - Running or runnable / low-priority , а
> > после и приспан  S /за да чака другия край /, а grep може ли да е (а може
> > и да не е [1] ) все още стартиран камо ли пък поставен в състояние S -
> > Interruptible sleep.
>
> В момента в който ps напълни буфера write-a blockva и scheduler-a почва да
> си върши работата. В момента в който четенето от другата страна изпразни
> буфера ps се маркира като runnable.

Добре ще блокира писането и пайпа при препълване, за това няма спор / и вече 
писането четенето няма да е атомично /. Незнам scheduler-a дали веднага ще 
switch-не към друг таск или ще чака края на timeslice-a. Но ако изхода на ps 
не препълни буфера и излезе преди края на неговия timeslice то каквото и да 
прави scheduler се оказва, че нашия grep не е бил процес докато е работил ps 
и за това няма как да го види (дори и да са в пайп).

Т.е. от всичкото това писане мисълта ми беше, че (не)появяването на grep в 
този случай е доста трудно предвидимо, най-малкото защото процесите в 
системата флуктуират и при всяко стартиране ps може да работи различно 
дълго/кратко и да не види процеси които ще бъдат стартирани след неговото 
приключване и поставянето на изхода му в буфера с големина PIPE_BUF 
(/usr/include/linux/limits.h)

-- 
pub 4096R/0E4BD0AB 2003-03-18 <danchev.fccf.net/key pgp.mit.edu>
fingerprint    1AE7 7C66 0A26 5BFF DF22 5D55 1C57 0C89 0E4B D0AB