- Forum
- UNIX/Linux Programming
- Creating new process
Creating new process
closed account (SNTRko23)
Hey guys!
I have a problem and was wondering if anyone could help?
I'm currently working on a 3D simulator that *must* run a certain section of code in parallel. My original plan was to encapsulate all of the code within a single class, then create multiple instances of the class, each one in a new thread; however, after attempting this, I received numerous segmentation faults which seem to stem from a library the class is using (i.e. ODE).
I then tried another approach - forking the process prior the section where parallelism was required, and it worked fine (which I'm assuming is because there are now two copies of the library in memory?). This approach would be perfect, were it not impossible to call methods within the different child processes from the parent process.
Is there any way I could have a class, which runs in a new process when instantiated, and still be accessed via its method-calls as usual?
Alternatively, does anyone have any suggestions on how I might be able to implement parallelism without sharing the library and still having complete two-way communication between the different instances?
Any suggestions would be HUGELY appreciated.
Thank you :)
I have a problem and was wondering if anyone could help?
I'm currently working on a 3D simulator that *must* run a certain section of code in parallel. My original plan was to encapsulate all of the code within a single class, then create multiple instances of the class, each one in a new thread; however, after attempting this, I received numerous segmentation faults which seem to stem from a library the class is using (i.e. ODE).
I then tried another approach - forking the process prior the section where parallelism was required, and it worked fine (which I'm assuming is because there are now two copies of the library in memory?). This approach would be perfect, were it not impossible to call methods within the different child processes from the parent process.
Is there any way I could have a class, which runs in a new process when instantiated, and still be accessed via its method-calls as usual?
Alternatively, does anyone have any suggestions on how I might be able to implement parallelism without sharing the library and still having complete two-way communication between the different instances?
Any suggestions would be HUGELY appreciated.
Thank you :)
Ok, unless you are using vfork() and the right parameters, there is a huge difference between forking another process and creating a thread. If you need these "processes" to share data, then you will need to use threads. From what you are describing, my best guess is you are attempting to share data/state.
You will need to verify that the ODE library is thread-safe. (I know nothing about it.)
You will need to verify that the ODE library is thread-safe. (I know nothing about it.)
closed account (SNTRko23)
My main concern is getting stable parallel processing.
ODE appears not to be thread-safe, however I have no problems when forking - hence, I'm hoping I can create an instance of a class to run in a separate process, and then have a parent process control the child process via the class' interface.
I'm guessing this won't be possible - if so, what are my best options? Forking alone isn't acceptable, as I want one process to control a series of child processes.
ODE appears not to be thread-safe, however I have no problems when forking - hence, I'm hoping I can create an instance of a class to run in a separate process, and then have a parent process control the child process via the class' interface.
I'm guessing this won't be possible - if so, what are my best options? Forking alone isn't acceptable, as I want one process to control a series of child processes.
closed account (SNTRko23)
In fact, if there's any way to multithread, and assign each thread it's own copy of the library in memory, that too would solve the problem.
When you fork, the child process image becomes an identical copy of the parent, BUT, changes made by the parent are not seen by the child and vice versa. Ie, parent are completely independent except that the child starts with a copy of the parent's state.
So, while you can create an instance of a class in the parent and then have both the parent and child run it in separate processes, it is functionally equivalent to copy constructing the child's version from the parent's and
then concurrently running the two.
If ODE is not explicitly stated to be thread-safe, then I would assume it is not, and so multi-threading isn't an
option for you.
Sorry I cannot help you further -- I just don't know anything about ODE (not even what it is) or about what you
are trying to do.
So, while you can create an instance of a class in the parent and then have both the parent and child run it in separate processes, it is functionally equivalent to copy constructing the child's version from the parent's and
then concurrently running the two.
If ODE is not explicitly stated to be thread-safe, then I would assume it is not, and so multi-threading isn't an
option for you.
Sorry I cannot help you further -- I just don't know anything about ODE (not even what it is) or about what you
are trying to do.
closed account (SNTRko23)
Thanks jsmith!
I wonder, if I did fork the process, what's the best way to communicate between separate processes? I've been looking at pipes, but it all looks very messy.
I wonder, if I did fork the process, what's the best way to communicate between separate processes? I've been looking at pipes, but it all looks very messy.
On Un*x platforms you have various options:
pipes / named pipes
system v message queues
unix sockets
There is no "best" solution. Pipes are 1-to-1. Named pipes can be many-to-many.
I'd avoid system v message queues like the plague. Unix sockets are very similar
to named pipes.
pipes / named pipes
system v message queues
unix sockets
There is no "best" solution. Pipes are 1-to-1. Named pipes can be many-to-many.
I'd avoid system v message queues like the plague. Unix sockets are very similar
to named pipes.
Shared memory could be an option as well I guess. And pipes aren't all that messy IMHO.
Still - if you can work out the critical regions when using your shared lib, you could just protect those in you app and use threads...
But if you persist on going the fork() route, and given that the IPC load won't be huge, I'd use TCP sockets. Having one controlling/synchronizing process acting like the server and client processes connecting in would even allow you to run worker processes on remote hosts being OS agnostic (even if that's probably way out of scope) :-)
Still - if you can work out the critical regions when using your shared lib, you could just protect those in you app and use threads...
But if you persist on going the fork() route, and given that the IPC load won't be huge, I'd use TCP sockets. Having one controlling/synchronizing process acting like the server and client processes connecting in would even allow you to run worker processes on remote hosts being OS agnostic (even if that's probably way out of scope) :-)
Topic archived. No new replies allowed.