One SDL app forking to start another

SDL Development
1

I have one SDL application that forks and calls execve to start a second
SDL application, but the call to SDL_Init in the second application fails.
How can I cut all the SDL ties between the two apps, or even better
start the second app as a completely different process? (This is on Linux 2.2)

Thanks,

Eric.

2

I have one SDL application that forks and calls execve to start a
second SDL application, but the call to SDL_Init in the second
application fails.
How can I cut all the SDL ties between the two apps, or even better
start the second app as a completely different process? (This is on
Linux 2.2)

You can fork before calling SDL_Init() in the parent process, but I
assume this forking is occurring because of some user event.

I don’t think there is a way to fork() and disconnect all that shared
state, so you’ll probably have to find a way to relaunch your app in
the event that you want to fork.

What if you had a “bootstrap” app (that is non-SDL) that launched the
first app. Then if you need a second app, you exit the first app with a
status of, say 2 (use exit(2)). The bootstrap app sees that the first
app has quit (since it uses waitpid()), and also that the exit code is
2, then launches two apps instead of one. It’s convoluted, but I think
it could work.

-DOn Tuesday, August 27, 2002, at 07:04 PM, Eric Nielson wrote:

3

Eric Nielson:

I have one SDL application that forks and calls execve to start a
second SDL application, but the call to SDL_Init in the second
application fails.
How can I cut all the SDL ties between the two apps, or even better
start the second app as a completely different process? (This is on
Linux 2.2)

As soon as the program starts, create a pipe pair, then fork() your program.
Parent inits SDL, child wait.
When you need it, parent can write() a command to child() that will either
init SDL and start the application or fork() itself, so that it will remain
available for another fork() while its child starts the app.
Of course, this adds some overhead (the child process), but not so much.

Regards,
Francesco Orsenigo, Xarvh Project
http://freeweb.lombardiacom.it/xarvh/