Re: lug-bg: ps ax|grep sth

[Peter Pentchev <roam@xxxxxxxxxxx>]

On Tue, Jun 14, 2005 at 01:59:03PM +0300, 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.
> 
> Буфера се явява семафор, като напълването му не е необходимо и
> достатъчно условие за блокиране и разблокиране на съответните процеси. При
> забавяне от страна на writer-а примерно(изтичане на timeslice-a му), 
> reader-a може да прочете частично запълнен буфер.

Има и още един сценарий, при който grep не вижда самия себе си - именно
този, който аз всъщност имах предвид, като говорех за време за изпълнение :)

Това са стъпките, през които се минава за изпълнение на "ps ax | grep blah":

   1. shell: създава pipe (анонимен pipe)
   2. shell: fork към shell-ps
   3. shell: fork към shell-grep
  
   4. shell-ps: пренасочва стандартния си изход към единия fd на
      създадения pipe
   5. shell-ps: exec ps

   6. shell-grep: пренасочва стандартния си вход от другия fd на
      създадения pipe
   7. shell-grep: exec grep

   8. ps: събира информация за процесите
   9. ps: обработва вътрешно събраната информация, избира процеси, които
      да покаже и т.н.
  10. ps: пише по стандартния си изход

  11. grep: чете от стандартния си вход

Цялата работа е в това, че тази номерация е до голяма степен условна.
Стъпките, за които редът е наистина гарантиран, т.е. частичната
подредба, е както следва:

  1 2 3    (това се прави в parent shell-а)
  2 4 5    (това се прави в shell-а, който се готви да изпълни ps)
  3 6 7    (това се прави в shell-а, който се готви да изпълни grep)
  5 8 9 10 (това се прави от ps)
  7 11     (това се прави от grep)

При тази частична подредба е напълно възможно нещата да станат в ред,
различен от 1 2 3 4 5 6 7 8 9 10 11 - дори мен много силно би ме
учудило, ако станат точно в този ред :)  Има много, много начини да се
получи това, което имам предвид, но най-простото обяснение е следният
ред:

  1 2 3 4 5 6 _8_ _7_ 9 10 11

Да, стъпки 8 и 7 са разменени - нищо не гарантира, че ps ще започне да
събира информацията *след* като процесът *с име grep* вече е създаден!
Съвсем спокойно може да се получи така, че ps да си събере информацията
и чак тогава вторият shell-наследник да направи exec("grep") - и тогава
ps няма как да предположи, че след част от секундата в таблицата с
процеси ще се появи нещо, наречено grep, което ние очакваме да видим :)

Да не говорим, че нищо не пречи нещата да станат и в ред

  1 2 4 5 8 9 10 _3_ 6 7 11

...т.е. parent shell създава нов процес, той *веднага* изпълнява ps, ps
си събира информацията, блокира при писането по pipe-а, и в този момент
shell-ът родител създава shell-grep и т.н.  Тогава също няма начин grep
или дори shell-grep да се появи в изхода от ps.

Разбира се, това е малко опростено: пропуснал съм купчина context
switches, syscalls, блокиране при писане, блокиране при четене,
блокиране при събиране на информация и други различни неща, където
управлението може да бъде иззето от един процес и дадено на друг, което
още повече да обърка реда на изпълнение, а изобщо да не говорим за
timeslices или preemption.  Но според мен това е най-простата и
най-вероятната причина от време на време grep да не вижда себе си в
изхода на ps.

Поздрави,
Петър

-- 
Peter Pentchev	roam@xxxxxxxxxxx    roam@xxxxxxxx    roam@xxxxxxxxxxx
PGP key:	http://people.FreeBSD.org/~roam/roam.key.asc
Key fingerprint	FDBA FD79 C26F 3C51 C95E  DF9E ED18 B68D 1619 4553
No language can express every thought unambiguously, least of all this one.

Attachment: pgpQgBBvg8FVb.pgp
Description: PGP signature