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
