Thread: Exit(0) and Infinite Loop

Originally Posted by tabstop

Well, I still don't think there's anything portable you can do. According to my man pages here, you could turn _getchar_nolock into getchar_unlocked in POSIX, if that works for you in the first place. I've never used either, so I don't know what issues you'll run into.

Do you know of any quick and dirty ways to just end the program?

There's _exit.

Originally Posted by tabstop

There's _exit.

It still leaves the window open until I hit enter.

That's all I got, I'm afraid. The smart people will be back soon, we hope.

The smart people will be back soon, we hope.

Don't confuse me for one of those...

On my linux system I have a function fcntl(int fd, int cmd, ...) that can perform operations on file descriptors. It looks like one of them is to set the file descriptor to be non-blocking. I think it would look something like,

Code:

fcntl(0, F_SETFL, O_NONBLOCK);  /* 0 is the standard input fd */

I've never played with this stuff, so can't really say how or if it should work. Just a thought I had.

Also, why wasn't select() working? Are you saying on Windows select() only works on socket descriptors? What about poll(), does your system have one of those? Looks similar - wait for events on certain file descriptors and you can specify a timeout.

Just some suggestions,

Jason

AFAIK I don't have either of those options available to me. It seems the only option I have right now is to remove the fgets. Now, how can I have handle:

Code:

while (running) {
...
}

without dominating the system resources, but also having a way to break out of the loop?

Appologetic bump.

This is unfamiliar territory for me, but you could see what the Windows API offers in terms of console functions: http://msdn.microsoft.com/en-us/libr...10(VS.85).aspx

At this point I would start looking at my loop and seeing if I could redesign it so that the extra, unnecessary, stubbornly blocking call to fgets was avoided all together.

What are the conditions under which you decide you no longer want to collect any input?

Originally Posted by jason_m

This is unfamiliar territory for me, but you could see what the Windows API offers in terms of console functions: http://msdn.microsoft.com/en-us/libr...10(VS.85).aspx

At this point I would start looking at my loop and seeing if I could redesign it so that the extra, unnecessary, stubbornly blocking call to fgets was avoided all together.

What are the conditions under which you decide you no longer want to collect any input?

fgets needs to collect data as long as the bot is connected to the server (which, ideally, is 24/7). It only stops when one of the users on the server issues the !quit command. But by that point it's already too late. My half-assed fix was to remove the fgets altogether, and replace it with Sleep(1000). But I'm hoping this is only a temporary solution.

Can you post up to date code if you are still having a problem. I am not going to read 24 posts. Though I am sure they are all gems, I am just not that motivated of an individual.

I reproduced the issue with VC++ 6.0 with the following:

Code:

#include <windows.h>
#include <process.h>
#include <stdio.h>

unsigned int WINAPI ThreadFunc(void *p)
{
    Sleep(3000);
    exit(0);
    return 0;
}//ThreadFunc

int main()
{
    char buffer[128];
    HANDLE ht;

    ht = (HANDLE)_beginthreadex(NULL, 0, &ThreadFunc, 0, 0, 0);
    if (!ht)
    {
        fprintf(stderr, "Failed to start thread, le=%u", GetLastError());
        return 1;
    }//if

    puts("Thread will call exit(0) in 3 seconds...");

    fgets(buffer, sizeof(buffer), stdin);

    WaitForSingleObject(ht, INFINITE);
    puts("Returning from main()...");

    return 0;
}//main

Stepping into exit() with the debugger revealed a deadlock on the lock associated with the stdin stream. The same code compiled with VC++ 2008 (using MSVCR90.DLL) works as expected. The Posix behavior of exit() is similar.

gg

I wouldn't use WaitForSingleObject() in this case, as it can cause a deadlock (what is it, the spaghetti eating philosopher's paradox or something). Apparently in this case it does.

>> ... it can cause a deadlock ... Apparently in this case it does.
No, it doesn't. The code behaves the same with or without the wait using either CRT.

gg