That's all I got, I'm afraid. The smart people will be back soon, we hope.
Don't confuse me for one of those...The smart people will be back soon, we hope.
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,
I've never played with this stuff, so can't really say how or if it should work. Just a thought I had.Code:fcntl(0, F_SETFL, O_NONBLOCK); /* 0 is the standard input fd */
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:
without dominating the system resources, but also having a way to break out of the loop?Code:while (running) { ... }
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?
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:
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.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
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