perl can start new threads (in a unix environment) and so can C++ (in any modern environment)

you could write a perl program with multiple threads that launched a c++ program with multiple threads, each thread could launch another perl program (or connect back to the same process) and within 5 seconds you'd have a right big knot of threads.

with regard to "how" or "can" it be done; providing your c++ program can be executed, take parameters, do its threaded business, and then (optionally) return to perl, you'll be fine. I have no experience with the inline module, but important considerations are:

-whether or not a call from perl to a c++ program is syncronous or asyncronous, if it's asyncronous, then the perl program will run the c++ program, then exit or continue whatever it was doing. (this is always an issue in any threaded/spawning system, particularly if the system is implemented in a language/environment not designed with threading specifically in mind. INFACT it's more of a consideration when creators of the environment decide that developers don't need control of threading, and that it'd be 'helpful' to manage such things automatically o_O) the reason i say that, is because it's highly possible that perl's spawning of a c++ program creates a new thread for that process. in that case, you'll need to be able to call a routine in an active perl process (or call a new perl process) from c++; if you want to tell perl that the C++ program has finished. Of course, that may not be a problem, depends if calls aren't syncronous, and depends what you want to do...

which leads nicely to...

- what exactly is it that you want to do? multithreading isn't always the best solution to all problems - it's not neccessarily a faster way to do things, nor is it ever an easier way to do things. the fact that a (self-contained) application spawned from a perl script is or isn't multithreaded is of NO consideration to perl, spawning an exe is spawning an exe. but it is certainly worth considering what each thread (within that self contained application) is for, and whether each thread is required.

Matt

Thanks Matt..I have to ping several IPs and get the status.Without threading it is going to take so much time.I feel threading is necessary in this situation..(A thread will be called once for each IP).What u say?

That's a valid use of threads; but try to recycle them or make sure they're destroyed when they've finished their work.

Also, make sure they're not repeating time/memory consuming operations; I'm assuming you want to log data, either to a Perl/C++ process or to a datafile/database. Don't open the database/file in every thread, and/or don't spawn a new process to handle the result of each ping

Why is that you need to start/monitor the process from Perl? try and keep both programs entirely separate (i.e. able to perform independantly) but connect-able via parameterised calls/active reference passing. Bear in mind, it's always going to be easier to start a new instance of a program with parameters than connect to an (unrelated) active process and pass parameters. Also, bear in mind, if you do that after every ping (to send data to a Perl script) it's gonna start a new Perl script each time.

Why can't you keep the whole program in C++?

Matt

I am clubbing this application with another very related application which is in perl.So I need to do this in perl only.I m using Tk as my frontend. Tk is not safe with perl threads.seems there is a bug.(segmentation fault occurs when using Tk and thread in same application).
So I opted for using C++ threads.
In Inlining I have to create thread objects and join threads in perl( thread class alone written in c++).
i am thinking of processing each output(sent from c++ to perl) which I got in joining thread.(My only option is joining in perl.not c++ )...I have to explore an option in inline to put everything in a datafile.

thanks in advance for any suggestions.

If you need results in real time:

If, from Perl, the C++ spawn call is syncronous, you'll have to spawn the C++ app hundreds or more times, losing your speed advantage, and outputing the result in Perl each time. Alternatively, you'll need two SEPARATE Perl apps, one to launch the C++ app, and one to read in the data, in order to simulate asynchronisity.

If the call is asynchronous, you'll have to find a way from the C++ process to connect back to the Perl process; there is an easy way, named pipes. I've never experimented with them in Perl, the standard named piping package doesn't work in Windows apparently.

But the concept is simple; you have a named filehandle, that is connected at one end to the C++ program and at the other end to the Perl program, all data written by the C++ program can be read into the Perl program and outputted.

Effectively, it's polling a virtual file that is closed and opened very frequently; and that's the easiest way I can think to simulate it in a Windows environment. From the C++ app, open the file (watching for errors), write some data, close the file; if you hit errors, try to open it and write until no errors. At the same time, in the Perl app, in a loop, open the file (ignoring errors), if there's data, output it, then clear the file and close it. You may end up with some funny things going on. If you figure out how to write-protect or otherwise flag the file in windows, it'll be much more reliable.

Alternatively, if you don't need a reply in real time.

If the spawn call to the C++ program is synchronous, it's easy, return the output from the C++ process when the program finishes, and it should be the return value from the call in the Perl process. It should be as easy as that. If it's not, use a named file and read it in when the process finishes.

If the call is asynchronous, make the Perl program delete the named file, run the C++ process, and then loop in Perl until the file exists (When the C++ program makes it), or until the user presses some kind of escape key.

Should be easy

Matt