Exit(0) and Infinite Loop

This is a discussion on Exit(0) and Infinite Loop within the C Programming forums, part of the General Programming Boards category; Originally Posted by tabstop Well, I still don't think there's anything portable you can do. According to my man pages ...

  1. #16
    Registered User
    Join Date
    Aug 2008
    Posts
    67
    Quote Originally Posted by tabstop View Post
    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?

  2. #17
    and the Hat of Guessing tabstop's Avatar
    Join Date
    Nov 2007
    Posts
    14,185
    There's _exit.

  3. #18
    Registered User
    Join Date
    Aug 2008
    Posts
    67
    Quote Originally Posted by tabstop View Post
    There's _exit.
    It still leaves the window open until I hit enter.

  4. #19
    and the Hat of Guessing tabstop's Avatar
    Join Date
    Nov 2007
    Posts
    14,185
    That's all I got, I'm afraid. The smart people will be back soon, we hope.

  5. #20
    Registered User
    Join Date
    May 2008
    Posts
    87
    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

  6. #21
    Registered User
    Join Date
    Aug 2008
    Posts
    67
    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?

  7. #22
    Registered User
    Join Date
    Aug 2008
    Posts
    67
    Appologetic bump.

  8. #23
    Registered User
    Join Date
    May 2008
    Posts
    87
    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?

  9. #24
    Registered User
    Join Date
    Aug 2008
    Posts
    67
    Quote Originally Posted by jason_m View Post
    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.

  10. #25
    Banned master5001's Avatar
    Join Date
    Aug 2001
    Location
    Visalia, CA, USA
    Posts
    3,685
    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.

  11. #26
    Registered User Codeplug's Avatar
    Join Date
    Mar 2003
    Posts
    4,691
    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

  12. #27
    Banned master5001's Avatar
    Join Date
    Aug 2001
    Location
    Visalia, CA, USA
    Posts
    3,685
    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.

  13. #28
    Registered User Codeplug's Avatar
    Join Date
    Mar 2003
    Posts
    4,691
    >> ... 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

Page 2 of 2 FirstFirst 12
Popular pages Recent additions subscribe to a feed

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21