Re: [GNUnet-developers] W32 console woes

[Christian Grothoff]

On 01/07/2014 05:40 PM, LRN wrote:
> With gnunet-conversation we now have an application with interactive
> console UI. Which requires selecting on a console.
> Skip to the last paragraph for the important part.
> 
> I have found no way to wait (and thus select) on a console handle.
> Thus it will have to be done with a thread.
> That thread could work the same way the socket-selecting thread works
> (except that it will only wait for a single console, not for a set of
> them) - i.e. it will be woken when selecting is needed, then it will
> block on a read, and will either unblock and wake up everyone else, or
> keep blocking, in which case the main thread will force it to unblock
> by simulating a console write; then the waiter thread will go to sleep
> until the next select call.
> 
> OR it could be implemented as a constantly-working thread that just
> always reads from console, puts read data into a buffer and maintains
> an event object that is set as long as there are events in the buffer,
> thus allowing the main thread to just wait on that event.

OR we could do our usual trick and fork another helper process to
interact with the console ;-).

> The advantage of the second way is that it doesn't have a hacky wakeup
> mechanism of the first way. That mechanism may eat input events (if
> the user presses something between the main thread waking up on
> timeout and generating a fake input event, then the waiter will
> discard actual user input and leave the fake one in the queue).
> The disadvantage of the second way is that it involves having a
> thread, which is something grothoff absolutely does not want to have,
> even if it's only for W32.
> 
> Which leads me to the question: do we really need interactive console
> on Windows? Maybe it's better to just make a simple gtk+-based
> conversation app and use that for testing purposes instead of
> gnunet-conversation (i sincerely hope that gnunet-conversation IS for
> testing purposes only, not for real end-users)?

Well, I can see it being used by people that don't like the state of
X security, so it's intended for a bit more then testing.  However,
yes, you're totally right that it's not for "real" end-users and that
I hope to have a gtk+ GUI "soon".

Still, the question how one should deal with a console is a reasonable
thing to discuss, as this might not be the last interactive console
application we ever write...


Happy hacking!

Christian