My question about how windows works without fork got pointers to two useful Windows perl modules in the comments:
Spawning External Programs
(from dagolden) See Win32::Job or just use system(1, $cmd, @args)
Creating Daemons
(from Christian Walde) Use Win32::Detached
What I was really wondering about was how reliable software was written without fork. What do I mean by that?
What is the difference between?
parent fork() do_something_independent() wait_for_childs_response()
and
parent thread() do_something_independent() wait_for_childs_response()
If the child thread misbehaves – exits, dumps core, leaks memory, or whatever, that’s bad for the parent. Child processes can’t wreak quite so much havoc.
Presumably the solution adopted in Window is don’t do stuff in threads that causes them to accidentally exit [the whole process], dump core or leak memory.
Or there id Win32::Process and its Create function. That is probably as ‘close to the metal’ as it is possible to get.
(Apologies if this shows up twice.)
Leigh
I recently needed to make a serial program run asynchronously/parallel/like fork but not since it Windows…
It needed to run on Windows so I eventually turned to threads.
Specificallly,
threads.
Thread::Queue
Both are core modules.
I posed the question on perlmonks and got good feedback.
Personally, the hard part was to figure out that I needed 2 queues (thus Thread::Queue). The first was a job queue where I dumped everything I need to process.
My biggest problem was figuring out how to get data back out from the threads in a sane manner. So I needed to create a second queue that the threads dumped their data into.
The finally bit of grokking was how I needed to modify my initial subroutine that did most of the work (and called several other subroutines).
I’ll try to find the various URLs that helped me and create a summary on my blogs.perl.org blog.
gizmo
Hi Leigh, I thought Win32::Job uses Win32::Process under the covers. Could be wrong though.
@gizmomathboy – I’d be interested to read a post like that, cheers.
Thanks for the shoutout.
As for your revised question:
Since fork won’t work right on windows i just never use it and avoid things that do.
Since threads don’t work right on linux i just never [1] use them and avoid things that do.
Better solutions are: As mentioned, spinning out independent activities into extra processes, manually spawned with the likes of open3 and connected via pipes, or network servers.
Alternatively, powerful tools exist for solving problems without threads or fork: Coro provides the ability to create light-weight fibers in a single-thread process between which the developer can switch when they deem it time to switch. AnyEvent and kids provides easy asynchronous processing for IO-bound activities.
[1]: Here’s a rather old and terrible OpenGL perl program where i used Detached, Coro and Threads, although i only used the threads for a minimal part and only because i knew this would never run on linux: http://code.google.com/p/dwarvis/source/browse/trunk/lifevis/Lifevis/Viewer.pm
Jared,
The other comments here are a lot more thoughtful than mine. You mentioned a couple of modules and ‘system’. The modules you mention are indeed very useful. I just thought it was useful to get Win32::Process into the record, as that is the lowest level module that’s available.
Leigh.
Hi Leigh,
Your comment was good. For sure I don’t want to discourage any helpful comments – I learn a lot from blogging here.
@Christian – I didn’t know that perl threads don’t work correctly on Linux. I generally prefer AnyEvent myself and resort to fork when I want to have the protection I’ve alluded to above.
@Jared: Since the context was perl i figured it’d be understood that i am talking about perl threads.