WindowsDriver and CursesDriver's MainLoops use an Action incorrectly

[tig]

The right fix is to change both Windows and Curses' MainLoop implementations to do this:

IOW, get rid of the ProcessInput Action alltogether and just have them call ProcessInput on the driver directly.

I tested it and it appears to work fine. Am I missing something (I probably am).

Originally posted by @tig in #2911 (comment)

[BDisp]

I tested it and it appears to work fine. Am I missing something (I probably am).

Yes you are missing. You can also do it for the NetDriver.
CursesDriver handles differently, because it use file descriptor that will check for revents. If exist a revent then it will call the event attached by the Watch instance.

[tig]

I tested it and it appears to work fine. Am I missing something (I probably am).

Yes you are missing. You can also do it for the NetDriver. CursesDriver handles differently, because it use file descriptor that will check for revents. If exist a revent then it will call the event attached by the Watch instance.

I applied the same change to CursesDriver and it seems fine.

• I made ProcessInput internal on
• I removed the WinChange Action
• I added a private reference to CursesDriver to UnixMainLoop
• I now call _cursesDrivder.ProcessInput (); instead of invoking WinChange?.Invoke()

See #2922

[tig]

Related, the file descriptor watching in the CursesDriver is unnecessary functionality. I don't think any apps use it, and even if they do, they can just use native unix APIs or the .NET file system watcher classes instead.

I think we should remove it.

[BDisp]

Related, the file descriptor watching in the CursesDriver is unnecessary functionality. I don't think any apps use it, and even if they do, they can just use native unix APIs or the .NET file system watcher classes instead.

I'm curious to see what you'll do. Only to remember that ncurses isn't compatible with .NET. Don't confuse the NetDriver with CursesDriver. Descriptors are native unix APIs.

I think we should remove it.

If you intend to use Console.ReadKey and remove ncurses at all, then is better to remove CursesDriver too.

[tig]

Related, the file descriptor watching in the CursesDriver is unnecessary functionality. I don't think any apps use it, and even if they do, they can just use native unix APIs or the .NET file system watcher classes instead.

I'm curious to see what you'll do. Only to remember that ncurses isn't compatible with .NET. Don't confuse the NetDriver with CursesDriver. Descriptors are native unix APIs.

I really mean just making AddWatch/RemoveWatch internal.

I think we should remove it.

If you intend to use Console.ReadKey and remove ncurses at all, then is better to remove CursesDriver too.

That is not my intent at this point.

Can you help me understand what the two AddWatch calls each do?

This one's obvious: It's watching for input:

But what is this one doing?

[BDisp]

Yes the prior is for input and the second is reading for any writing done on the _wakeUpPipes. The later is useful for cancelation or from a post of the threading synchronization, normally by calling the Wakeup method which will interrupt the poll function and thus ensuring a new run loop.

Edit:
Pay attention that the Wakeup method isn't used to cancel a cancellation token but only to wake while awaiting a keystroke. That why I was using in the WindowsDriver and NetDriver the keyReady.Set to wake and not cancellationToken.Cancel.

[tig]

Please review changes now in this PR. More to do, but this is a massive simplifier... I think.

[BDisp]

Please review changes now in this PR. More to do, but this is a massive simplifier... I think.

I already reviewed. Thanks.