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 _______________________________________________ GNUnet-developers mailing list GNUnet-developers@gnu.org https://lists.gnu.org/mailman/listinfo/gnunet-developers
