Re^13: Thread Design help

Given your very vague specifications, I would very strongly consider using completely separate programs. Both, fork and threads will consume many resources and make debugging your program very hard.

As you need to perform very different tasks (connect via ssh, connect via DBI, ...), putting all the code for these different tasks into one program makes little sense.

Have one central program that starts the specific programs as separate children. Consider maybe Parallel::Jobs or simple open "$child |" to run your child processes in parallel.

But before thinking about how to do things in parallel, I really, really urge you to first get things working in a serial fashion.

Comment on Re^13: Thread Design help Select or Download Code

Replies are listed 'Best First'.
Re^14: Thread Design help by perlCrazy (Monk) on Sep 11, 2010 at 17:52 UTC
Thanks for response. For ssh and DBI we will have two separate programs, and will be easy to maintain. for running in sequential, we will have problem. Example: there is poosility of delay in process for few servers and might create problem when report won't be available on time. I am thinking to use Thread::queue, will divide servers into 10-15 groups and kick off programm with GRP1..N as input parameter. example: 1. collector. pl GRP1 ## GRP1 will contain 30-40 dataserver Please suggest if this approach is not efficient. Thanks	[reply]
Re^15: Thread Design help by Corion (Patriarch) on Sep 11, 2010 at 20:36 UTC
You have two wars to fight: Retrieve information from services Parallelize tasks As I see it, you are currently neither clear of which has a higher priority, and what each task is to do. I really recommend that you separate the concerns. You can easily parallelize the task of information retrieval by starting programs in parallel. So do that instead of worrying about fork or threads.	[reply]