Multithreading/Process c++ question

[JRowe]

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.

[JRowe]

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 October 31, 2008 by jrowe

[monoceres]

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?

[Valik]

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.

[monoceres]

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.

[JRowe]

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.

[Valik]

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.