Talk:Fork: Difference between revisions
m (Talk:Fork Proccess moved to Talk:Fork Process: Don't need an extra c in "process") |
(→Clojure and Haskell examples: new section) |
||
| Line 1: | Line 1: | ||
This appears unclear to me -- is the forked process supposed to be the same as the forking process or just any odd old process? How does this differ from [[Simple_concurrent_actions]]? At what level is the fork supposed to happen (does it have to have a different OS-level pid or can it run as a parallel script on the same interpreter, for example). I guess my biggest conceptual trouble is understanding what that process is supposed to <i>do</i>: "Fork a process" is like "build a machine" - without any spec as to the machines <i>purpose</i>, I wouldn't know what to do. On some level, every GUI program on modern hardware consists of many parallel processes already (mouse and kbd interactions, video display, file i/o, all possibly at the same time) so I'm guessing the new process should do something beyond merely "existing" - but what?[[User:Sgeier|Sgeier]] 20:04, 14 March 2007 (EDT) |
This appears unclear to me -- is the forked process supposed to be the same as the forking process or just any odd old process? How does this differ from [[Simple_concurrent_actions]]? At what level is the fork supposed to happen (does it have to have a different OS-level pid or can it run as a parallel script on the same interpreter, for example). I guess my biggest conceptual trouble is understanding what that process is supposed to <i>do</i>: "Fork a process" is like "build a machine" - without any spec as to the machines <i>purpose</i>, I wouldn't know what to do. On some level, every GUI program on modern hardware consists of many parallel processes already (mouse and kbd interactions, video display, file i/o, all possibly at the same time) so I'm guessing the new process should do something beyond merely "existing" - but what?[[User:Sgeier|Sgeier]] 20:04, 14 March 2007 (EDT) |
||
*Simple Concurrent Actions is a bit broader than Fork Process because it includes the possibility of using threads for the concurrent behavior, not just processes.[[User:Waldorf|Waldorf]] 18:56, 14 March 2007 (MDT) |
*Simple Concurrent Actions is a bit broader than Fork Process because it includes the possibility of using threads for the concurrent behavior, not just processes.[[User:Waldorf|Waldorf]] 18:56, 14 March 2007 (MDT) |
||
== Clojure and Haskell examples == |
|||
I marked the Clojure and Haskell examples as incorrect. forkIO creates a new thread, not a process. A clojure agent runs on one of the threads in a thread pool, within the same process. -- [[User:Wmeyer|Wmeyer]] 08:58, 17 January 2010 (UTC) |
|||
Revision as of 08:58, 17 January 2010
This appears unclear to me -- is the forked process supposed to be the same as the forking process or just any odd old process? How does this differ from Simple_concurrent_actions? At what level is the fork supposed to happen (does it have to have a different OS-level pid or can it run as a parallel script on the same interpreter, for example). I guess my biggest conceptual trouble is understanding what that process is supposed to do: "Fork a process" is like "build a machine" - without any spec as to the machines purpose, I wouldn't know what to do. On some level, every GUI program on modern hardware consists of many parallel processes already (mouse and kbd interactions, video display, file i/o, all possibly at the same time) so I'm guessing the new process should do something beyond merely "existing" - but what?Sgeier 20:04, 14 March 2007 (EDT)
- Simple Concurrent Actions is a bit broader than Fork Process because it includes the possibility of using threads for the concurrent behavior, not just processes.Waldorf 18:56, 14 March 2007 (MDT)
Clojure and Haskell examples
I marked the Clojure and Haskell examples as incorrect. forkIO creates a new thread, not a process. A clojure agent runs on one of the threads in a thread pool, within the same process. -- Wmeyer 08:58, 17 January 2010 (UTC)