console input/ouput at the same time

[doublex]

Hi guys, got a bit of a problem here with the console :S

Basically I have a few threads running at the same time, one of them is continuously getting input (std::cin.getline(), and the others are printing realtime data retreived via winsock.

My problem is that if you are halfway through typing a message, and another thread prints to the console, it all gets jumbled.
Picture here: http://www.aurj64.dsl.pipex.com/MessedUpConsole.jpg

Causing the output threads to wait until input has been received to print, is not an option.

Any suggestions would be appreciated

[philkr]

What about using a critical section for the print operation?

[doublex]

What about using a critical section for the print operation?

Could you eloborate a bit please? I've never heard that term before :s

EDIT: ok I just read up a bit on critical sections, although I'm not sure how they could help. The thing is, I need the print function to happen as soon as the message is received, its not an option to wait until the user has finished typing. Equally, it is not an option for the text which has been written so far when printf is called, to be lost.

Any ideas how to implement a critical section to meet these requirements, or any other method to solve this problem?

It's getting on my nerves as I'm sure there must be a simple solution

[Krishnaa]

Could you eloborate a bit please? I've never heard that term before :s

You can not write and read from console at same time, if you are using threads, you should use critical section before printing and reading from console.
See CRITICAL_SECTION.

[doublex]

You can not write and read from console at same time, if you are using threads, you should use critical section before printing and reading from console.
See CRITICAL_SECTION.

Thanks Krish, I've read up a bit about mutex's/critical sections now, but I honestly can't see how they would help in this situation, the problem being that because a user typing a message will take such a long time, the print function would be delayed by an unacceptable length of time.
Can you think how to apply a critical section to this, or a different method maybe?

[Krishnaa]

Thanks Krish, I've read up a bit about mutex's/critical sections now, but I honestly can't see how they would help in this situation, the problem being that because a user typing a message will take such a long time, the print function would be delayed by an unacceptable length of time.
Can you think how to apply a critical section to this, or a different method maybe?

Just to make sure that writing reading dosent get mixed.

[doublex]

I'm not sure if you understand what I'm trying to accomplish-

One thread must be able to instantly print whatever it wants, to the same console that must constantly be receiving input.

If you've ever had experience with the console in games such as 'quake' or 'half life', thats what I'm trying to acheive

[Krishnaa]

Well, game console and Windows console are realy not the same. Those are customsed text outputs. Sometimes normal windows.

The windows console is character based, you could get result as mixed text if multiple threads read/write at same time. Which is why you should lock a syncronication object before using console read/write from threads.

[doublex]

Well, game console and Windows console are realy not the same. Those are customsed text outputs. Sometimes normal windows.

The windows console is character based, you could get result as mixed text if multiple threads read/write at same time. Which is why you should lock a syncronication object before using console read/write from threads.

Yup I know they are different things, however for a minor home project I don't think coding my own console in a win32 window is worth the time it would take.
When you are half way through entering text into a console input, is there not an API or something, that could read the text before you press the enter key?

[GaboonViper]

isn't there some way to combine th two threads into one? Cause the way i see it, two threads are just making everything more difficult than it should be. In my opinion threads should only be used if they can work besides eachother without having to exchange information between them.

[philkr]

I see now that critical sections don't help with your problem, but nevertheless they seem to be useful, because you are writing from multiple threads.
I think with getline() there is no way to achieve what you want, because the user always has to press enter. One solution might be to use a function, which only reads one character. Everytime a key is hit, you will know which character it was. You can then print it and append it to a buffer, which you will terminate with a zero once you received a return.

[Luis G]

Why not print in one portion of the screen and input in another?
Look for conio.h or ncurses.h, dunno if there's a C++ equivalent.

[doublex]

I see now that critical sections don't help with your problem, but nevertheless they seem to be useful, because you are writing from multiple threads.
I think with getline() there is no way to achieve what you want, because the user always has to press enter. One solution might be to use a function, which only reads one character. Everytime a key is hit, you will know which character it was. You can then print it and append it to a buffer, which you will terminate with a zero once you received a return.

Y'know thats a pretty good idea, the best I've heard so far.

To the post saying multiple threads are more complicated, well they are, but it's unavoidable I'm afraid. This program is a server, which uses blocking winsock sockets, one socket in each thread, and one thread per client, plus the console input thread.

Why not print in one portion of the screen and input in another?
Look for conio.h or ncurses.h, dunno if there's a C++ equivalent.

Thats another good idea, which I will try, failing the getting characters individually method.

Thanks guys ^_^