Jump to content
  • Advertisement
Sign in to follow this  
Verg

exit()ing an external process [RESOLVED]

This topic is 4864 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

{EDIT to close thread] Rather than post again to this, and bump it to the top... I'll edit the head message... It seems I had "module" and "process" a bit confused; any time a .dll is loaded by a process, it is mapped into that process' address space... so "exit()" and "_exit()" will both work, from either the parent module or the DLL. BTW the crash handling .dll is coming along very well... all we have left to do is pop up the actual dialog... it is logging everything very well. [/EDIT] Been buildin' a heap-nice crash handler for our apps... Buidling it into a separate DLL which isn't loaded into the current process' address space, to keep the stack(s) separate and process memory separate, so that when an unhandled exception occurs, the Dialog box pops up (out of the DLL) and nothing (stack/memory) from the main process is touched (or, touched very much [smile] ) Simple question really... What is the best way, after returning all the information to the user, of getting the main process (.exe) to end? Currently, the Policy class we're using for that is called "AllowCrash", which just sends the unhandled exception back, and pops up Microsoft's crash dialog. This is undesired. We'd like our dialog to be the "last word" before the app quits. "exit()" seems to be good, "_exit()" may be better... but these exit the current process... and if the exception handler (made of policies) is inside the dll, we can't run "exit()" in there... (it would cause the .dll to unload!) Should/can we: 1) Pass a static pointer (to a Terminator object) to a .dll function... which object exists in the .exe process... which would simply run "exit()" inside the .exe? Will that work? Thanks for any reply. Chad [Edited by - Verg on July 24, 2005 4:15:49 PM]

Share this post


Link to post
Share on other sites
Advertisement
IOW, this is what I'm asking...

//will this work?

//PSEUDO-CODE


// somewhere inside main prog (.exe)

DllFunc(&m_staticTerminatorObject);

// in DllFunc:

void DllFunc(Terminator *terminator)
{
Set Exception handler with "terminator" ptr...
}

// when Exception handler is ready to end

terminator->exit();

// with static instance of "Terminator" created in main process... and...

void Terminator::exit()
{
_exit(3);
}

Share this post


Link to post
Share on other sites
Quote:
Original post by bytecoder
TerminateProcess sounds like it does what you want.


Thanks man... I have seen TerminateProcess...

Yep; but TerminateProcess isn't (in MSDN's words) "the preferred method of exiting a process"...

...then again, a seg-fault isn't the preferred course of action for an app, either [smile]

It's a question of:

...what process is running the ExceptionHandler anyway? It's being called by the system... but since the .dll wasn't loaded by the .exe at runtime...

If the ExceptionHandler, which is instantiated inside the .dll, is being called by the .exe's process, then I could call _exit() directly.

...

If only there were a way to run _exit() from the .exe's process after the ExceptionHandler's had its way... a way to message the .exe process to _exit() immediately... (without using Windows' messages... the .exe process, remember, is in a broken state...)

TerminateProcess may be the only solution then... hrmmm...

Share this post


Link to post
Share on other sites
How about a thread in the original process? One that checks the existance of a mutex, or something?

Say... if the mutex exists, it would call _exit()?

So... when the .dll's process creates the mutex, the .exe's Termination thread would call _exit()?

Or... do all threads get suspended when the application hits a seg-fault?

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!