Sign in to follow this  
Followers 0
JRowe

Multithreading/Process c++ question

7 posts in this topic

I was just thinking that c++ can handle multi-threading just fine... is there a way to clone a process into it's own thread? E.G. arbitrarily coopt a process?

The only example of what I'm thinking of is as follows: Could you write a c++ program that launched a single process, then ran firefox in one thread, and internet explorer in the other? (not precisely that, there would be lots of issues, but that's the gist of my idea.)

If that's possible, then genuine multithreading is possible for AutoIt by coopting script processes and using a plugin to access a message queue / scheduler script. No language changes required, just a different programming style (managing a message stack and scheduling events, etc.)

I'm running into issues with irrlicht, doing minor things, so I thought I'd explore this possibility.

Share this post


Link to post
Share on other sites



#2 ·  Posted (edited)

So:

1.) It's too easy an idea for other people not to have thought of it

2.) Given 1, it's probably not possible, since it hasn't been done already.

Coopting a script or a process would probably require abstracting the entire AutoIt engine, and that's not an option.

However, spawning a separate thread with a plugin function seems possible, so spawning two threads... one as a message queue, the other as a function, then having the function send data to the queue, and calling an AutoIt function to get data from the queue, would work, I think.

Lots of good information here:

http://www.devarticles.com/c/a/Cplusplus/M...threading-in-C/

Off I go again.

Edited by jrowe

Share this post


Link to post
Share on other sites

Hmm I'm a bit confused here. Are you saying that you want to run processes inside your process, each separated into individual thread, but in the same address space? And then be able to communicate with the processes from a main thread?


Broken link? PM me and I'll send you the file!

Share this post


Link to post
Share on other sites

You are missing the entire point of what multi-threading is. The reason multi-threading exists is so that single-threaded code that would otherwise require a lot of manually written synchronization code can be done by the OS/processor. It also allows for a bit better organization by allowing variables to be shared. It cuts down on the amount of code tremendously - when used correctly.

Your first suggestion is just... bad. It's pretty non-trivial to run a process *inside* the address space of another process. It's not practical to do it although it is technically possible.

Second, if you're going to implement a bunch of synchronization code manually, why do you need threads at all? Two processes communicating is going to be the same thing as if you were to get two threads communicating using the methods you describe. Without core changes to AutoIt, you aren't going to be able to share variables between "threads". You're going to have to marshal all your data yourself. Since you're going to have to marshal this data yourself, there really isn't any reason not to just use two processes and save yourself a ton of work.

Share this post


Link to post
Share on other sites

It's pretty non-trivial to run a process *inside* the address space of another process. It's not practical to do it although it is technically possible.

Do you know any article/resource/general info on this subject? I have been interested in it for some time now and I'm unable to find anything worth reading.


Broken link? PM me and I'll send you the file!

Share this post


Link to post
Share on other sites

Oh, absolutely, I'm gonna have to do some sort of message queue regardless of the details. I guess I'm just trying to figure out the easiest way to control a game from AutoIt, and I keep running into the need to keep game logic, gui, rendering, and physics separate. Easiest example is to drag one of the Au3Irrlicht windows, and the simulation freezes.

Without core changes to AutoIt, you aren't going to be able to share variables between "threads".

That's what I was after, because I need to share variables from the rendering engine with the audio and physics portions of a game. I suppose this means I should integrate the rendering, audio, and physics all into one Engine that is callable via AutoIt, instead of integrating each separately, using AutoIt as glue. (cue aneurysm)

The only beef I have with the multiple process approach is that having one program launch a slew of processes seems kludgy. I can get over that really easily, but I wanted to see if it was avoidable.

Thanks... I know you've answered more than your share of multithreading questions, of varied relevance. I appreciate the input.

Share this post


Link to post
Share on other sites

Do you know any article/resource/general info on this subject? I have been interested in it for some time now and I'm unable to find anything worth reading.

There could be but if you were able to understand any article on the subject then you'd already know enough to do it, anyway. Otherwise the article would be pretty massive if it provided the necessary background information required.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!


Register a new account

Sign in

Already have an account? Sign in here.


Sign In Now
Sign in to follow this  
Followers 0