| … | |
… | |
| 124 | For example, when a program uses an event loop and creates watchers it |
124 | For example, when a program uses an event loop and creates watchers it |
| 125 | becomes very hard to use the event loop from a child program, as the |
125 | becomes very hard to use the event loop from a child program, as the |
| 126 | watchers already exist but are only meaningful in the parent. Worse, a |
126 | watchers already exist but are only meaningful in the parent. Worse, a |
| 127 | module might want to use such a module, not knowing whether another module |
127 | module might want to use such a module, not knowing whether another module |
| 128 | or the main program also does, leading to problems. |
128 | or the main program also does, leading to problems. |
|
|
129 | |
|
|
130 | Apart from event loops, graphical toolkits also commonly fall into the |
|
|
131 | "unsafe module" category, or just about anything that communicates with |
|
|
132 | the external world, such as network libraries and file I/O modules, which |
|
|
133 | usually don't like being copied and then allowed to continue in two |
|
|
134 | processes. |
| 129 | |
135 | |
| 130 | With this module only the main program is allowed to create new processes |
136 | With this module only the main program is allowed to create new processes |
| 131 | by forking (because only the main program can know when it is still safe |
137 | by forking (because only the main program can know when it is still safe |
| 132 | to do so) - all other processes are created via fork+exec, which makes it |
138 | to do so) - all other processes are created via fork+exec, which makes it |
| 133 | possible to use modules such as event loops or window interfaces safely. |
139 | possible to use modules such as event loops or window interfaces safely. |
