a4e
Subj : Re: Why it doesn't work ??
To   : comp.programming.threads
From : David Butenhof
Date : Tue Oct 04 2005 02:47 pm

tarkan2097@hotmail.com wrote:
> Hi Everybody. I'm trying to develop a small program to run multiple
> SHELL scripts in parallel using threads. The problem is that I don't
> see the function executed by the threads. Can someone help me to debug
> this. I'm getting fustrated now.

Your limited code sample shows only that you're creating threads; each 
locks a mutex (but you don't show the unlock, much less any other form 
of synchronization)... and there's no hint anywhere of what you mean by 
"run [...] SHELL script".

I'm not aware of any shell that can be run "as a thread". You'd need a 
sort of thread-safe shell runtime library; that is, something like a 
"shell()" routine you could call directly from your code, passing a 
filename of a shell script, or even a list of commands.

Most of the time, "running shell commands using threads" just means that 
your individual threads will fork shell commands (or scripts) in 
parallel. But fork() is a PROCESS operation that's not really parallel, 
and the SHELL itself will run in a child process, with the thread in 
your parent process just waiting for it to complete with wait*().

Besides, even if you had a "shell()" function you could call in a 
thread, remember that nearly every "shell command" on a UNIX family 
system (or Windows or Mac OS X for that matter) is in fact a PROGRAM 
that the SHELL would fork as a child process. So it's not at all clear 
that such a "thread-safe shell library" would be particularly useful to 
anyone.

In principle you could build a completely new system where every command 
(including the shell) was a dynamically loadable thread-safe library; so 
that your program could call the shell, and it would load and call the 
commands in the script. Of course now you've lost security domains 
between the commands, you've got a single fat and busy process instead 
of a bunch of smaller processes... and again it's not at all clear that 
you've solved any problems or improved anything. But it would be an 
intriguing experiment. ;-)

But as to why your program doesn't WORK (whatever it's actually trying 
to do, and whatever the relationship might be between that and what you 
think you would have liked it to do), there's not enough code shown to 
guess.

-- 
Dave Butenhof, David.Butenhof@hp.com
HP Utility Pricing software, POSIX thread consultant
Manageability Solutions Lab (MSL), Hewlett-Packard Company
110 Spit Brook Road, ZK2/3-Q18, Nashua, NH 03062

.

0