作者 主題: [轉貼] Process Creation概念問題  (閱讀 5888 次)

0 會員 與 1 訪客 正在閱讀本文。

netman

  • 管理員
  • 俺是博士!
  • *****
  • 文章數: 17403
    • 檢視個人資料
    • http://www.study-area.org
[轉貼] Process Creation概念問題
« 於: 2003-08-05 11:51 »
"老貢生" <letsgo@ms6.url.com.tw> 撰寫於郵件 news:3F2C5094.4020306@ms6.url.com.tw...
> kalle wrote:
> > ※ 引述《hazi.bbs@bbs.cis.nctu.edu.tw (無限的海)》之銘言:
> >
> >>轉信站: KimoWebBBS!netnews.kimo.com.tw!news.csie.ncu!news.mgt.ncu!news.ncu!ctu-
> >>Origin: 61-225-114-152.HINET-IP.hinet.net
> >>==> 在 mattbiaskalle@yahoo.com.tw (kalle) 的文章中提到:
> >>
> >>>在operating system concepts 4th,p107,process creation中,
> >>>a new process is created by the fork system call.
> >>>可否有人能更實際地說解釋這個fork?
> >>>我的意思是說比如我在run 一個程式,其中又fork,
> >>>然後我是不是有兩個程式在執行?
> >>>這樣之下,是不是兩個一樣的程式同時執行?
> >>>只不過是各別的program counter不一樣?
> >>>(比如說是另一個新生出來的process
> >>>同時執行程式中不一樣區段的程式碼?)
> >>>
> >>是兩個完全不同的 process,它們的 memory space 也不同。
> >>可以看做兩個不相關的程式在執行。
> >>但是兩個 process 也是有一些溝通的方式,請查詢一下 IPC。
> >>
> >
> > 那這樣要做什麼用?
>
> 本尊與分身的關係,或許孫猴子用一根毛變化萬千小猴子的例證可以解釋,
> 每個小猴子都是孫悟空的一部分,但卻可以自己獨立行動。那為何要那麼多分身
> ,因為小 case 給小猴子做,每件事都動本尊反而費事。
>
> > 是不是這樣就兩個在程式中不同部份,可以同時執行?
>
> 基本上都是小猴子出馬,孫悟空就進入等待狀態,一直到小猴子行動結束,
> 孫悟空再出馬。除非有特殊訊息到來,喚醒孫悟空,那就會把小猴子先
> 丟到背景,由孫悟空出馬,出馬完再換小猴子上。
>
> 那如果有不只一隻小猴子上場呢,那就要孫猴子本身有輪詢的功能,為每個小猴子
> 分配執行時間,所以推到最原本,每個執行程式,其實都是作業系統的小猴子。
>
> p.s.
> 比較嚴謹一點的說法是,function 和 fork  對主程式來說,都是
> 一個可被呼叫的區段,但兩者的不同是,當 function 被主程式呼叫時,
> 他沒辦法被插斷,主程式只有等他執行完畢後返回,但 fork 區段執行時,
> 主程式可以被插斷,去先執行其他的事後,再返回 fork。
>
> 所以只有能 fork 的設計,主程式才有 listen 的功能,
> listen 正是所有多工作業系統的最先決條件。
>
> > 網頁那邊有example ?
> >



"potus" <potus@bbs.openfind.com.tw> 撰寫於郵件 news:0BGJ646$0000J06$1@bbs.openfind.com.tw...
> ※ 引述《mattbiaskalle@yahoo.com.tw (kalle)》之銘言:
> > ※ 引述《letsgo@ms6.url.com.tw (老貢生)》之銘言:
> > > 轉信站: KimoWebBBS!netnews.kimo.com.tw!news.csie.ncu!news.ncu!ctu-peer!Spring!n
> > > Origin: u52-53.u203-204.giga.net.tw
> > > kalle wrote:
> > > 本尊與分身的關係,或許孫猴子用一根毛變化萬千小猴子的例證可以解釋,
> > > 每個小猴子都是孫悟空的一部分,但卻可以自己獨立行動。那為何要那麼多分身
> > > ,因為小 case 給小猴子做,每件事都動本尊反而費事。
> > > 基本上都是小猴子出馬,孫悟空就進入等待狀態,一直到小猴子行動結束,
> > 這樣看起來就跟副程式呼叫!
> 這個比喻和fork本身沒有關係﹐它只是fork的一個應用。
>
> > > 孫悟空再出馬。除非有特殊訊息到來,喚醒孫悟空,那就會把小猴子先
> > > 丟到背景,由孫悟空出馬,出馬完再換小猴子上。
> > > 那如果有不只一隻小猴子上場呢,那就要孫猴子本身有輪詢的功能,為每個小猴子
> > > 分配執行時間,所以推到最原本,每個執行程式,其實都是作業系統的小猴子。
> > > p.s.
> > > 比較嚴謹一點的說法是,function 和 fork  對主程式來說,都是
> > > 一個可被呼叫的區段,但兩者的不同是,當 function 被主程式呼叫時,
> > > 他沒辦法被插斷,主程式只有等他執行完畢後返回,但 fork 區段執行時,
> > > 主程式可以被插斷,去先執行其他的事後,再返回 fork。
> > 主程式fork產生新process之後,程式繼續go on !
> > 兩個process同時執行~!
> fork和一般的system call並無不同﹐呼叫fork的程式同樣要等fork結束之後返回﹐
> 才能繼續執行fork呼叫之後的程式。它的副作用是新產生一個process。兩個
> process(parent and child)檢查fork的return value以決定自己的角色。如果
> 等於零﹐那是child,不然就是parent。之後它們可以繼續執行同一個程式﹐也可以
> 分道揚鏢。後者是一般的情況﹐譬如開機時﹐process 1(init) 就fork好幾個process,
> 每個process用exec把自己從init變成getty。當你login時﹐再變成login,最後變成
> login shell。
>
> > > 所以只有能 fork 的設計,主程式才有 listen 的功能,
> > > listen 正是所有多工作業系統的最先決條件。
> > 這種fork之後產生一個process,依據我讀恐龍那一本書的理解,
> > 這個fork 出來的 process 跟原來的process一樣,
> > 不過看程式, 好像fork後就直接call 一個副程式,
> > 因此變成原來的process與fork出來的process同時多工執行!
> > 如果不用fork而直接call call 一個副程式,這就是副程式呼叫!
> > 這樣不知對不對?
> 我想你指的listen是指類似xinet這種程式﹐包含了一般listen,accept及
> connect的功能。
> 多工﹐fork及listen並沒有因果的關係﹐多工並不一定要listen或fork,譬如一個process
> 數目固定的embedded system﹐它仍然是一個多工系統。
>


"老貢生" <letsgo@ms6.url.com.tw> 撰寫於郵件 news:3F2DA0FE.2030305@ms6.url.com.tw...
> potus wrote:
> > ※ 引述《mattbiaskalle@yahoo.com.tw (kalle)》之銘言:
> >
> >>※ 引述《letsgo@ms6.url.com.tw (老貢生)》之銘言:
> >>
> >>>轉信站: KimoWebBBS!netnews.kimo.com.tw!news.csie.ncu!news.ncu!ctu-peer!Spring!n
> >>>Origin: u52-53.u203-204.giga.net.tw
> >>>kalle wrote:
> >>>本尊與分身的關係,或許孫猴子用一根毛變化萬千小猴子的例證可以解釋,
> >>>每個小猴子都是孫悟空的一部分,但卻可以自己獨立行動。那為何要那麼多分身
> >>>,因為小 case 給小猴子做,每件事都動本尊反而費事。
> >>>基本上都是小猴子出馬,孫悟空就進入等待狀態,一直到小猴子行動結束,
> >>>
> >>這樣看起來就跟副程式呼叫!
> >>
> > 這個比喻和fork本身沒有關係﹐它只是fork的一個應用。
> >
> >
> >>>孫悟空再出馬。除非有特殊訊息到來,喚醒孫悟空,那就會把小猴子先
> >>>丟到背景,由孫悟空出馬,出馬完再換小猴子上。
> >>>那如果有不只一隻小猴子上場呢,那就要孫猴子本身有輪詢的功能,為每個小猴子
> >>>分配執行時間,所以推到最原本,每個執行程式,其實都是作業系統的小猴子。
> >>>p.s.
> >>>比較嚴謹一點的說法是,function 和 fork  對主程式來說,都是
> >>>一個可被呼叫的區段,但兩者的不同是,當 function 被主程式呼叫時,
> >>>他沒辦法被插斷,主程式只有等他執行完畢後返回,但 fork 區段執行時,
> >>>主程式可以被插斷,去先執行其他的事後,再返回 fork。
> >>>
> >>主程式fork產生新process之後,程式繼續go on !
> >>兩個process同時執行~!
> >>
> > fork和一般的system call並無不同﹐呼叫fork的程式同樣要等fork結束之後返回﹐
> > 才能繼續執行fork呼叫之後的程式。它的副作用是新產生一個process。兩個
>
> 你這話有點前後矛盾,先說 fork 和一般 system call 並無不同,但又說
> 他有產生新一個 process 的副作用,那我們這麼說好嗎,我們就是要
> 利用這個 fork 特有的副作用,而且這個副作用關係大了。
>
> > process(parent and child)檢查fork的return value以決定自己的角色。如果
> > 等於零﹐那是child,不然就是parent。之後它們可以繼續執行同一個程式﹐也可以
> > 分道揚鏢。後者是一般的情況﹐譬如開機時﹐process 1(init) 就fork好幾個process,
>
> 同樣的問題請教?如果你用其他的 system call 而不用 fork ,
> 他們可能分道揚鑣嗎?
>
> > 每個process用exec把自己從init變成getty。當你login時﹐再變成login,最後變成
> > login shell。
> >
> >
> >>>所以只有能 fork 的設計,主程式才有 listen 的功能,
> >>>listen 正是所有多工作業系統的最先決條件。
> >>>
> >>這種fork之後產生一個process,依據我讀恐龍那一本書的理解,
> >>這個fork 出來的 process 跟原來的process一樣,
> >>不過看程式, 好像fork後就直接call 一個副程式,
> >>因此變成原來的process與fork出來的process同時多工執行!
> >>如果不用fork而直接call call 一個副程式,這就是副程式呼叫!
> >>這樣不知對不對?
> >>
> > 我想你指的listen是指類似xinet這種程式﹐包含了一般listen,accept及
> > connect的功能。
> > 多工﹐fork及listen並沒有因果的關係﹐多工並不一定要listen或fork,譬如一個process
> > 數目固定的embedded system﹐它仍然是一個多工系統。
>
> 我想請問,如果作業系統沒有 listen ,他怎樣決定那個 process 有繼續執行權利,
> 又如何分配系統資源?作業系統的運作模式基本上和 xinet 並沒有太大的差異,
> 只是一個是 listen 網路 request ,一個是 listen 執行程序之間彼此的
> request 而已。
>
> 我說如果沒有多 process 機制就沒有多工作業系統成立的話,fork
> 是產生 process 用的,那是不是 fork 是多功的重要機制呢?
> 如果你一定要舉有那種 embed system 固定就有好幾個 process
> 就由 process 控制,不需要 fork ,我不能否認,但那也只是特例,
> 大部分 linux kernel 的運作方式卻是大量使用 fork 機制來
> 產生他的多工效能的。
>
> p.s.
> 我知道 fork 也是一種 function call ,但我們現在要談的是這種
> call 跟一般的 call 有什麼特別不一樣的地方。
>




"potus" <potus@bbs.openfind.com.tw> 撰寫於郵件 news:0BGLL7N$000082R$1@bbs.openfind.com.tw...
> ※ 引述《老貢生<letsgo@ms6.url.com.tw》之銘言:
> > potus wrote:
> > > 這個比喻和fork本身沒有關係﹐它只是fork的一個應用。
> > > fork和一般的system call並無不同﹐呼叫fork的程式同樣要等fork結束之後返回﹐
> > > 才能繼續執行fork呼叫之後的程式。它的副作用是新產生一個process。兩個
> > 你這話有點前後矛盾,先說 fork 和一般 system call 並無不同,但又說
> > 他有產生新一個 process 的副作用,那我們這麼說好嗎,我們就是要
> > 利用這個 fork 特有的副作用,而且這個副作用關係大了。
>
> 一點都不矛盾﹐它只是指出每個system call的呼叫流程並無不同﹐且說明你之前
> 【fork 區段執行時,主程式可以被插斷,去先執行其他的事後,再返回 fork】
> 的說法是不對的。就功能而言﹐每個system call當然都做不同的事。
>
> > > process(parent and child)檢查fork的return value以決定自己的角色。如果
> > > 等於零﹐那是child,不然就是parent。之後它們可以繼續執行同一個程式﹐也可以
> > > 分道揚鏢。後者是一般的情況﹐譬如開機時﹐process 1(init) 就fork好幾個process,
> > 同樣的問題請教?如果你用其他的 system call 而不用 fork ,
> > 他們可能分道揚鑣嗎?
> > > 每個process用exec把自己從init變成getty。當你login時﹐再變成login,最後變成
> > > login shell。
> > > 我想你指的listen是指類似xinet這種程式﹐包含了一般listen,accept及
> > > connect的功能。
> > > 多工﹐fork及listen並沒有因果的關係﹐多工並不一定要listen或fork,譬如一個process
> > > 數目固定的embedded system﹐它仍然是一個多工系統。
> > 我想請問,如果作業系統沒有 listen ,他怎樣決定那個 process 有繼續執行權利,
> > 又如何分配系統資源?作業系統的運作模式基本上和 xinet 並沒有太大的差異,
> > 只是一個是 listen 網路 request ,一個是 listen 執行程序之間彼此的
> > request 而已。
>
> 這差異太大了。xinet這種server是被動得等待﹐一般time sharing的kernel
> 其scheduling卻是定時主動﹐除非當前的process主動放棄﹐但從user space
> 經過system call到進入kernel space,都還是同一個process在run。
>
> > 我說如果沒有多 process 機制就沒有多工作業系統成立的話,fork
> > 是產生 process 用的,那是不是 fork 是多功的重要機制呢?
> > 如果你一定要舉有那種 embed system 固定就有好幾個 process
> > 就由 process 控制,不需要 fork ,我不能否認,但那也只是特例,
> > 大部分 linux kernel 的運作方式卻是大量使用 fork 機制來
> > 產生他的多工效能的。
> > p.s.
> > 我知道 fork 也是一種 function call ,但我們現在要談的是這種
> > call 跟一般的 call 有什麼特別不一樣的地方。
>



"網路黑貓" <champ.bbs@bbs.sayya.org> 撰寫於郵件 news:47WffL$643@bbs.sayya.org...
> fork()是Un*x中用來產生新process的唯一system call
>
> 系統呼叫fork()主要有三個情形
>
> 1.System Initialization
>   在開機時, 系統第一個process是init, 接著init使用fork()去產生其他
>   開機過程的process
>
> 2.Execution of a process creation system call by a running process
>   一個執行中的程式過程中呼叫fork()來處理事務. 像是multiprocess的
>   server
>
> 3.A user request to create a process
>   使用者利用shell去執行程式.
>
> 基於1., 所以一個Un*x系統中process的架構事實上是一個以init為root
> 的tree
>
> 統合1.,2.,3, 一個process都有上一層的process, 該process稱為parent
>
> fork()的使用方式
>
>     int pid = fork();
>     if(pid == 0){
>        //child process
>        ...............
>     }else{
>        //parent process
>        ...............
>     }
>
> 程式的流程會是這樣
>
>     process1 -> fork() -> if{...}
>                  |
>                  |(process2 is created)
>                  v
>     process2    fork() -> else{...}
>
> process1呼叫fork(), kernel會在複製process1,
> 在process table內產生新的record
> 新的process2就產生了
> 新產生的process是從呼叫fork()該行開始執行
> 但兩個程式是彼此互不相關的, (process1 和process2 是無關的)
> 雖然剛執行完fork()兩個process有著相同的環境
> (變數/記憶體內的數值和環境變數, server會利用此點去使child處理事務)
> 然而一個process更動數值並不會影響另一個process
> 而在1.&3.的情形中, 通常是執行 execve()去執行另一個程式
> (在此之前, 通常會做standard input/output的redirect)
> 此時child和process記憶體內的資料就不同了
>
> 所以letsgo兄所提的猴子理論, 基本上是2.的應用
> 開機過程靠的是1.,2.
>
> 但是letsgo兄對於fork()原理的解釋是錯的
> child process要執行是靠kernel的process scheduler
> process1呼叫fork()後, kernel會處理child的執行時機,
> parent之後就不管了, 除非彼此有IPC的影響
> 一旦child一產生, 其執行的權力就跟parent相同(除非特別去調整)
> 而不是倚靠parent去中斷再去執行child
> 執行child process是kernel的事情,
> 雖然child執行時parent一定沒在執行(single CPU架構下)
>
> 而且fork()跟listen()是無關的
> listen()是network server的API, socket-accept-listen是可以只有one process的
> 只是這樣的server只允許同時處理一個client
>
> 而potus對於listen的解釋是錯的
> xinted是利用network API加上fork()去達到您所說的功能
> 而不是listen是指xinetd程式
> 但是potus對於fork的觀念是正確的
>
> 至於letsgo兄提到kernel怎麼決定那個程式有執行的權力
> 這還是跟fork()無關的
> 這得談到kernel內的process scheduler和process states.
>
> 想要知道更詳細的相關資料可以參考
> 1.Modern Operating System - by Andrew S. Tanenbaum
> 2.Linux Kernel Programming
> 3.Advanced Programming in Unix Network Programming - by Richard Steven
> 4.Unix Network Programming - by Richard Steven




"老貢生" <letsgo@ms6.url.com.tw> 撰寫於郵件 news:3F2F07B4.9060103@ms6.url.com.tw...
> potus wrote:
> > ※ 引述《老貢生<letsgo@ms6.url.com.tw》之銘言:
> >
> >>potus wrote:
> >>
> >>>這個比喻和fork本身沒有關係﹐它只是fork的一個應用。
> >>>fork和一般的system call並無不同﹐呼叫fork的程式同樣要等fork結束之後返回﹐
> >>>才能繼續執行fork呼叫之後的程式。它的副作用是新產生一個process。兩個
> >>>
> >>你這話有點前後矛盾,先說 fork 和一般 system call 並無不同,但又說
> >>他有產生新一個 process 的副作用,那我們這麼說好嗎,我們就是要
> >>利用這個 fork 特有的副作用,而且這個副作用關係大了。
> >>
> >
> > 一點都不矛盾﹐它只是指出每個system call的呼叫流程並無不同﹐且說明你之前
> > 【fork 區段執行時,主程式可以被插斷,去先執行其他的事後,再返回 fork】
>
> 你要談程式我們就來談程式流程走向,一般的副程式,譬如是 100 行到
> 兩百行是個函式區段,那一般的函式呼叫是從 100 行一直執行到 200 行,
> 直到第二百行都執行完了,才回到呼叫敘述的下一行執行。但
> fork 不是,fork 呼叫完 kernel 給他一個新 process 後,就由
> 系統來掌控這個新的 process ,原來的父程式直接跳到呼叫敘述的下一行
> 執行。也就是如果一般函式的呼叫,就算被排程程序分配到執行權,他也要乖乖的把
> 整個區段執行完,但 fork 出去的區段,那就不管新 process 執行到哪一行,
> 只要原 process 一得執行權就直接呼叫函式後一行執行。
>
> 而我說的主程式插斷,就是說在排程程序輪到該主程式執行時,該主程式
> 可以不再去管那個新 process ,直接去處理其他的事。直到他用完分配時間,
> 排程程序就會把執行權力交給其他 process 使用,就會回到原來
> fork 出去的那個 process 上。
>
> 當然,依你的慣例,你一定又要說這不叫插斷,隨便了,反正意思到了就好,
> 我本不堅持要叫什麼。
>
> > 的說法是不對的。就功能而言﹐每個system call當然都做不同的事。
>
> 請注意,原發問者是問 fork 和一般的 system call 有何不一樣,
> 所以我是針對 fork 的特性在討論的。
>
> >
> >
> >>>process(parent and child)檢查fork的return value以決定自己的角色。如果
> >>>等於零﹐那是child,不然就是parent。之後它們可以繼續執行同一個程式﹐也可以
> >>>分道揚鏢。後者是一般的情況﹐譬如開機時﹐process 1(init) 就fork好幾個process,
> >>>
> >>同樣的問題請教?如果你用其他的 system call 而不用 fork ,
> >>他們可能分道揚鑣嗎?
> >>
> >>>每個process用exec把自己從init變成getty。當你login時﹐再變成login,最後變成
> >>>login shell。
> >>>我想你指的listen是指類似xinet這種程式﹐包含了一般listen,accept及
> >>>connect的功能。
> >>>多工﹐fork及listen並沒有因果的關係﹐多工並不一定要listen或fork,譬如一個process
> >>>數目固定的embedded system﹐它仍然是一個多工系統。
> >>>
> >>我想請問,如果作業系統沒有 listen ,他怎樣決定那個 process 有繼續執行權利,
> >>又如何分配系統資源?作業系統的運作模式基本上和 xinet 並沒有太大的差異,
> >>只是一個是 listen 網路 request ,一個是 listen 執行程序之間彼此的
> >>request 而已。
> >>
> >
> > 這差異太大了。xinet這種server是被動得等待﹐一般time sharing的kernel
> > 其scheduling卻是定時主動﹐除非當前的process主動放棄﹐但從user space
> > 經過system call到進入kernel space,都還是同一個process在run。
>
> 真要凡事從開天闢地談起,那我就說豈只是 xinet 是被動,整個 linux
> 萬千 process ,除了一個排程程序是主動外,其他都是被動,不要
> 說 server 是被動等待,所有的大小系統程序,使用者程序都在被動等待,
> 問題是這樣講有意義嗎?就好像人家說我的機車有 24 匹馬力,時速最高
> 300 公里,你非要凹回去一句,你錯了,是你的機車引擎有 24 匹馬力,
> 不是機車。
>
> >
> >
> >>我說如果沒有多 process 機制就沒有多工作業系統成立的話,fork
> >>是產生 process 用的,那是不是 fork 是多功的重要機制呢?
> >>如果你一定要舉有那種 embed system 固定就有好幾個 process
> >>就由 process 控制,不需要 fork ,我不能否認,但那也只是特例,
> >>大部分 linux kernel 的運作方式卻是大量使用 fork 機制來
> >>產生他的多工效能的。
> >>p.s.
> >>我知道 fork 也是一種 function call ,但我們現在要談的是這種
> >>call 跟一般的 call 有什麼特別不一樣的地方。
>



"網路黑貓" <champ.bbs@bbs.sayya.org> 撰寫於郵件 news:47XCfF$8Lf@bbs.sayya.org...
> ※ 引述《letsgo@ms6.url.com.tw (老貢生)》之銘言:
> > 我對二位只有一個感覺,明見秋毫,不見輿薪,網路黑貓所舉的例證,不斷的說明
> > linux 不斷的利用 fork() 來展開各個 process ,達成多工多人使用的
> > 問題,結論卻是我說 fork 對系統多工處理重要的觀念是錯的,而 potus
> > 的 fork 對多工處理沒特別意義的觀念是對的?
>
> 說真的, 我真的覺得閣下在硬坳了
> 先看看閣下的原文好了
>
> "比較嚴謹一點的說法是,function 和 fork  對主程式來說,都是
> 一個可被呼叫的區段,但兩者的不同是,當 function 被主程式呼叫時,
> 他沒辦法被插斷,主程式只有等他執行完畢後返回,但 fork 區段執行時,
> 主程式可以被插斷,去先執行其他的事後,再返回 fork。"
>
> 所以只有能 fork 的設計,主程式才有 listen 的功能,
> listen 正是所有多工作業系統的最先決條件。
>
> 基本上fork對於parent process呼叫, 真的跟一般的function call無異
> 是等fork()的動作kernel處理好, 才繼續下一行
> 您這樣解釋真的是不對的.
> parent process也必須等到fork執行完再繼續執行之後的程式碼
> 何來先執行其他事情後再返回fork的道理?
>
> 後面扯到listen
> 還說listen是多工作業系統先決條件, 這真的是蠻扯的
>
> 我想請問,如果作業系統沒有 listen ,他怎樣決定那個 process 有繼續執行權利,
> 又如何分配系統資源?作業系統的運作模式基本上和 xinet 並沒有太大的差異,
> 只是一個是 listen 網路 request ,一個是 listen 執行程序之間彼此的
> request 而已。
>
> 看看之後您說您不堅持甚麼, 叫甚麼, 或許我該問你listen到底是甚麼了
> 作業系統運作模式跟xinetd沒有太大差異!?
> 這個問題之前有人已經提出回覆了, 我就不說了, 但是真的差太遠了
>
> 不過我建議閣下把OS關於process management重新看一下
>
> 再看看您後來回覆的這段話
>
> 你要談程式我們就來談程式流程走向,一般的副程式,譬如是 100 行到
> 兩百行是個函式區段,那一般的函式呼叫是從 100 行一直執行到 200 行,
> 直到第二百行都執行完了,才回到呼叫敘述的下一行執行。但
> fork 不是,fork 呼叫完 kernel 給他一個新 process 後,就由
> 系統來掌控這個新的 process ,原來的父程式直接跳到呼叫敘述的下一行
> 執行。也就是如果一般函式的呼叫,就算被排程程序分配到執行權,他也要乖乖的把
> 整個區段執行完,但 fork 出去的區段,那就不管新 process 執行到哪一行,
> 只要原 process 一得執行權就直接呼叫函式後一行執行。
>
> 而我說的主程式插斷,就是說在排程程序輪到該主程式執行時,該主程式
> 可以不再去管那個新 process ,直接去處理其他的事。直到他用完分配時間,
> 排程程序就會把執行權力交給其他 process 使用,就會回到原來
> fork 出去的那個 process 上。
>
> 這樣的說法跟您之前的講法又不同,
> 之前是把兩個process的流程扯在一起
> 一下扯listen, 一下又趕緊把process schedule扯進來
> (還是您要說您不堅持process schedule要叫啥, 所以叫listen?)
> 而且這段話和您最早說的意思也不同, listen也不見了
> 這段話開始承認了兩個process間的獨立, 而不是
> "主程式可以被插斷,去先執行其他的事後,再返回 fork。"
> 只是這裡又故意把這個部分移花接木到比較正確的說法
>
> 而且一般function call的呼叫誰規定分配到執行權時要乖乖的把整個區段執行完?
> context switch是kernel決定不是process決定的
> 這裡的說法好似function call必須做完否則不能context switch
> 而fork就可以中斷去context switch給其他process做事
> context switch這對所有process在kernel都是對等的跟fork無關
> 而fork對於parent跟所有function call都一樣, 執行完就回到原本程式的下一行
>
>
> 當然,依你的慣例,你一定又要說這不叫插斷,隨便了,反正意思到了就好,
> 我本不堅持要叫什麼。
>
> 這不是您堅不堅持要叫甚麼的問題
> 您的想法有問題, 而且您的用詞也有問題
> 一切都隨您高興的話, 何不叫callback 或是 java or some else?
> 用字遣詞的精確的重要性若能像您這般無賴, 那我想政客也不足為奇了
>
> > 其他細節,沒力氣再多說了,反正看者愛信那種,隨人了。
> 藉此話來混淆自己說的是正確的?
>
>
> 有機會至少看一下
> OS的書
> 資工常用書 - 恐龍本(雖然我不覺得這本講的很好)
> Operating System Implementation & Desing - Tanebaum
> Modern Operating Operating System - Tanebaum
>
> Tanebaum的Minix關於PM的部分也可以看看
> (Linux kernel我不敢奢望)
>



"網路黑貓" <champ.bbs@bbs.sayya.org> 撰寫於郵件 news:47XD89$60O@bbs.sayya.org...
> ※ 引述《letsgo@ms6.url.com.tw (老貢生)》之銘言:
> > > 的說法是不對的。就功能而言﹐每個system call當然都做不同的事。
> > 請注意,原發問者是問 fork 和一般的 system call 有何不一樣,
> > 所以我是針對 fork 的特性在討論的。
> 請看原文, 不要自己自由心證
>
> > > 這差異太大了。xinet這種server是被動得等待﹐一般time sharing的kernel
> > > 其scheduling卻是定時主動﹐除非當前的process主動放棄﹐但從user space
> > > 經過system call到進入kernel space,都還是同一個process在run。
> > 真要凡事從開天闢地談起,那我就說豈只是 xinet 是被動,整個 linux
> > 萬千 process ,除了一個排程程序是主動外,其他都是被動,不要
> > 說 server 是被動等待,所有的大小系統程序,使用者程序都在被動等待,
> > 問題是這樣講有意義嗎?
> 差多了
> xinetd靠的是listen被動的去等待, 等到有client來才運作
> 否則多半是處於block狀態
> 您之前說"OS運作模式原理同xinetd"
>
> 沒錯所有process都是被動, 只有"OS主動分配執行權給process"
> 您把process跟server比當然是相同, 但您要談的是OS, 這樣比的邏輯又何在?
> 所以那樣講是有意義的...
>
> 您也說了"除了一個排程程序是主動外,其他都是被動"
> PM是OS的一部分, 這正是突顯OS與xinetd運作方式南轅北轍



"小州" <kenduest.bbs@bbs.sayya.org> 撰寫於郵件 news:47XL9F$9SR@bbs.sayya.org...
> ※ 引述《letsgo@ms6.url.com.tw (老貢生)》之銘言:
> > 在你心心念念只想更小更快的同時,你為何不先想想有什麼是 process
> > 做得到,而 thread 做不到的呢 ?以及為何在 linux 下多用 process
> > 而少用 thread 呢?真的只是因為 thread 比較高 coding 困難而已嗎?
>
>   當一個執行中的程式要產生許多分身執行許多工作時,一般 unix 系統
>   作法就是產生許多子行程,也就是透過 fork() 產生 multi processes,
>   而每個產生出來的 process 有其獨立的空間運作。
>
>   若是 process 與 process 要進行資料交換溝通,有 pipe、IPC (shm...)
>   等等一堆運作機制來達成,這是另外一個課題。
>
>   thread,稱呼為執行緒,某些情況來看可以簡單的稱呼為 lightweight
>   process,也就是輕量級行程。
>
>   使用 thread,產生出來所有的 thread 並不像是 fork() 產生出來的行程
>   都佔用獨立的記憶體區塊。相反地,multi-thread 程式佔用相同記憶體
>   位置,能夠共享相同的資料區塊。
>
>   使用 thread 好處在於,thread 不大像是傳統 fork 呼叫要產生兩個獨立
>   的行程,通常耗費系統記憶體空間資源會比較低。另外,對於產生出來兩個
>   分身之間要進行資料溝通交換比較簡單,檔案存取非同步 IO、數值計算與
>   繪圖介面使用 thread 來達成平行來處理會很有用與方便。
>
>   thread 進行資料存取,還有另外 synchronization、semaphores 的問題,
>   這也是另外一個議題。
>
>   目前已經有許多 unix 平台支援 multi-thread programming API 介面,
>   像是 Sun Solaris、Digital Unix 後來版本也都已經納入。Linux 對於
>   thread 支援,一開始是發起 linux thread 計畫,後來已經於 glibc 2.x
>   後正式納入之。
>
>   multi-thread programming 的確不好搞,這是事實。就 coding 層面來看,
>   傳統 unix 的 fork 方式,呼叫 fork() 後由傳回值就可以判定目前 process
>   是 parent process 還是 child process,剩下就各自進行其工作項目了。
>
>   而使用 multi-thread  programming 來看,一開始就要使用 pthread_create
>   呼叫並傳入一堆參數,後續控制層面還是另外一門學問。像是 synchronization
>   與 semaphores 注意處理部份不少。
>
> --