is there a way to do Console.ReadLine() asynchronously?
what the title says. it's always a blocking method, no matter which way you spin it, so im not sure if there's like a workaround or something
20 Replies
directly on
Console are helper methods for the different streams, Console.In, Console.Out and Console.Error provide a richer API.
Console.In.ReadLineAsync()yeah but that method is explicitly stated to be broken:
oh
then there probably isnt a way
🔫
found a hacky af way
i put it in a async method and.. dont await the async method
this will probably cause some drastic error but uh
Why do you even need an asynchronous API?
making a simple chatbox app because im testing lite net lib (im probably doing this wrong)
and if ReadLine() is blocking then you cant really recieve any messages
Hello,
I 'm just thinkng of what you want to do. Even if you can wait for a inputline, this wouldnt work. The problem is that the main text is printed in the console and also waiting. So you cant block without having a chat window different from a input window.
However if you only want the program process to continue you could do the following:
- create an object async and start it with e.g. task / background worker (completely loose from the main program).
- in the different thread add an event to communicate with the main program.
In short the console runs in another thread and the main program is informed for any input using an event subscription
i would do it vice versa.
do the blocking console stuff in the main thread and everything else which can work async throw onto the thread pool
often the main thread is the only foreground thread, thus it needs to stay active because thread pool threads are background threads
eg this little main method
becomes something like
thus because u have that thread anyway, u can also just put it to work for ur synchronous console reads
Choose you're self what you think is best. The following is just an explenation why I would do the input in a different thread (I would keep the main for controlling everything).
If you go to more advanced input ways you will not put the input in the main.
Just an example. If you create a windows form app. The main is the program. This starts a form and all textfields input fields use an event trigger. if there is a textfield with refreshing texts this is continioulsy updated from different input parts. In this case the input is also event driven.
Now we go further to a website.
I will simplify it (without the backend):
THe website exists of 2 parts a screen where the messages are shown and an input field. The input is only triggered when a button or an enter is done. The stream of messages keep on refreshing.
I know with Rust you have a message queue.
One channel for receiving the messages and one for sending them. A thread polls the messages and then sends the message to something which acts accordingly.
its not like it matters since i wont even be using this when it comes to LiteNetLib's actual intended purpose (for i'm pretty sure gamedev) i just wanted to know
Not sure why you are using such a library for something as simple as a chat application
getting acquainted i gues
I suggest using the library for something that requires more packets being sent, such as a real-time collaboration drawing app.
A chat app can be made really simple with a basic tcp socket.
No need for rUDP and so forth.
OK
I used it for a peer to peer collaboration app.
It's use is not exclusively for games, but can be adapted to anything.
sounds difficult but i could try
If you want to learn networking that is the way. Start with the basics, not a library that practically do everything for you.
And it does not need to be async if it is a console.
IO (Input Output) is blocking.
Console is not asynchronous
You likely don't need to do any asynchronous programming. Just check if there is input via
Console.KeyAvailable before calling Console.ReadKey. Then your program won't pause to wait for user input. You will need to add some extra logic because ReadKey only reads one input while ReadLine reads until the next new line, but that extra logic should be pretty trivial.