"non blocking" console input ?
Author
hi,
im currently working on networking my old pong clone... anyway, i want to give the server some commands, but the problem is that cin >> doesnt return till the user puts in input and presses enter. is there some way to rig it so that its "non blocking"? i guess i could just take input w / SDL, but its kind of a pain to get the raw input and stuff using SDL so id rather see if theres some other way to do it.
thanks for any help.
The simplest way would be to stick the part of your program waiting for console input in a seperate thread.
if you are using a console program then you may be able to do (pure C style)
HTH,
#include < conio.h > // console io...int c;for (;;) { if (_kbhit()) { c = getch(); // do whatever you want with c } else { // no kb input: do whatever you want }}HTH,
Quote:Original post by Emmanuel DelogetNonstandard and platform-specific.
if you are using a console program then you may be able to do (pure C style)
Fact is, non-blocking console I/O is nearly an oxymoron.
Author
so basically the only way around this is threads? also, why is it an 'oxymoron' ? do you think its a bad idea for me to do this or something? like i said, its for a server for my pong game (but will soon be expanded to the server for my 2d RPG), and id like to be able to do things on the server like type in commands such as "ping so and so" or "display users" or "kick soandso", etc.
thanks for any help.
PS - if threads are the only way... are they really that big of a deal to learn / use? ive never even tried to learn them before because i've had no use for them. are they tricky to use or is it pretty much strait forward or what?
thanks for any help.
PS - if threads are the only way... are they really that big of a deal to learn / use? ive never even tried to learn them before because i've had no use for them. are they tricky to use or is it pretty much strait forward or what?
SDL will let you deal with threads in an easy and cross-platform manner. The important thing is to make sure both threads don't try to use a variable at the same time. For example, if you have a string storing the command the user wants executed, you want to make sure the main thread doesn't try to read it while you're in the process of setting it, or you don't try setting it while the other is reading it. You would use a mutex for that. You lock it before you use it, and when you're done with it, you unlock it. If the other thread tries to lock the mutex, SDL_LockMutex will wait until the first thread has unlocked it before returning.
Threads are dangerously easy to use badly.
It takes ten seconds to fire off another thread and half-assedly synchronize it with your main thread using common variables - and it'll probably work in 99.9% of cases. Problem is, unless you know what you're doing you'll end up with a program that crashes once in a blue moon, or only on other peoples' computers, due to a timing issue.
Read up on synchronization and concurrent programming and you should be OK. Despite what Oluseyi said, though, if you aren't worried about platform independance _kbhit() will do the trick. Even if you are, just #define WaitForKey _kbhit and use #ifdefs to switch in the appropriate value for the current platform.
It takes ten seconds to fire off another thread and half-assedly synchronize it with your main thread using common variables - and it'll probably work in 99.9% of cases. Problem is, unless you know what you're doing you'll end up with a program that crashes once in a blue moon, or only on other peoples' computers, due to a timing issue.
Read up on synchronization and concurrent programming and you should be OK. Despite what Oluseyi said, though, if you aren't worried about platform independance _kbhit() will do the trick. Even if you are, just #define WaitForKey _kbhit and use #ifdefs to switch in the appropriate value for the current platform.
If you don't care about being platform independent, this will work on *nix-based machines. I don't know what headers include it, but it's part of the sockets implementation
fd_set read_fds, master; // File Descriptor set
struct timeval tv;
tv.tv_sec = 1; // Seconds
tv.tv_usec = 500; // Microseconds (NOT milli)
FD_ZERO(&read_fds); // Zero both of the structures
FD_ZERO(&master);
FD_SET(STDIN, &read_fds); // Add sockets to the set in the same manner.
master = read_fds;
for (;;) {
// As soon as data arrives on STDIN or another socket in
// the fd_set, this function will notify you of it, if
// nothing happens after the time specified in the timeval
// structure, execution continues.
select(STDIN+1, &read_fds, 0, 0, &tv);
if(FD_ISSET(STDIN, &read_fds)) { // Check if there's input from STDIN
// There's input, do something with it.
}
read_fds = master; // Reset the File Descriptor Set
}
fd_set read_fds, master; // File Descriptor set
struct timeval tv;
tv.tv_sec = 1; // Seconds
tv.tv_usec = 500; // Microseconds (NOT milli)
FD_ZERO(&read_fds); // Zero both of the structures
FD_ZERO(&master);
FD_SET(STDIN, &read_fds); // Add sockets to the set in the same manner.
master = read_fds;
for (;;) {
// As soon as data arrives on STDIN or another socket in
// the fd_set, this function will notify you of it, if
// nothing happens after the time specified in the timeval
// structure, execution continues.
select(STDIN+1, &read_fds, 0, 0, &tv);
if(FD_ISSET(STDIN, &read_fds)) { // Check if there's input from STDIN
// There's input, do something with it.
}
read_fds = master; // Reset the File Descriptor Set
}
Quote:Original post by Anonymous PosterThat's not despite what I said, that's exactly what I said: "Nonstandard and platform-specific."
Despite what Oluseyi said...
The console is a largely serial mechanism, so the facilities designed for it are designed around serial processing. Asynchronous processes, events, etc are more naturally suited to an asynchronous user environment (duh) like the GUI. All the posts after mine have merely confirmed my assessment.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
