Re: fork.pm

Steve,

At 18:08 -0800 2/24/04, Steve Schein wrote:
>How are you?

Fine, thank you...


>I just read your ithreads article in Perlmonks which you posted last
>year.  I didn't know you had written something and I enjoyed it
>immensely being a "Perl thread kinda guy."  As I was reading about
>fork.pm it occurred to me that I might be able to make good use of
>fork.pm but I wanted to check first.
>
>One of my applications is INET socket-intensive and currently I spawn
>threads each time I need to accommodate X number of users-per-socket.
>Data received by the sockets is stored in variables that are global to
>the class and shared using threads:shared.  The socket threads start up
>quickly and work just fine but I'm afraid that as I scale up the number
>of users I would get bogged down by using too many heavy threads.
>Another reason I'm pursuing this line of questioning is that these
>socket threads don't exchange data with other threads which is a point
>you made in the article.
>
>I also presume from the article that fork.pm isn't as heavy as ithreads
>since it doesn't copy resources (does it?) like ithreads does.
>
>Therefore, the goal for me would be to have something that is more
>scalable without losing the ability to write and read to/from shared
>variables in the forked process.
>
>Should I be taking a harder look at fork.pm?
>
>As always, I appreciate your thoughts and assistance.

If you're on Win32, then using forks.pm is of no use: you'd be on a 
system emulating threads with fork(), which is emulated by threads.

If you're not on Win32, then forks.pm might be of use.  However, as 
you're worried about performance, I don't think forks.pm may not be 
the solution for you, as there is quite some latency involved in the 
communication between threads.

With the information you've given me, I would probably redesign the 
application to use bare fork() (or maybe something like 
Parallel::ForkManager) and find some other way of sharing data 
between "threads".


Liz