Re: Is a "silent" ncurses initialization possible?

[Thomas Dickey]

On Mon, Jun 08, 2015 at 07:12:08PM +0200, Robin Haberkorn wrote:
> On Mon, Jun 08, 2015 at 05:10:29AM -0400, Thomas Dickey wrote:
> > On Thu, Jun 04, 2015 at 03:24:00PM +0200, Robin Haberkorn wrote:
> > > 
> > > screen = newterm(NULL, screen_tty, screen_tty);
> > 
> > This is the problem: "/dev/null" is not a tty device, so the system
> > calls which rely upon that will fail.  ncurses allows this (rather than
> > refusing to open it in newterm), but returns the error status from the 
> > various
> > functions (such as cbreak).
> >
> Of course it is not a tty-device. But later on, I freopen() `screen_tty`
> with the tty-device.
> Why does cbreak() still fail then?

cbreak tries to update the tty mode, and fails.  It sounds as if ncurses
is still holding a descriptor to the non-tty device, which is not necessarily
the one that you get from freopen.  (Something to check on, anyway).
 
> Nevertheless, I think I'll just extend Scinterm in the manner described
> to get it working before initializing ncurses (or any curses) via initscr().
> 
> Btw. I do know it's possible to open /dev/tty with newterm() in the first
> place. I used to do it in SciTECO as well. This will leave stdin/stdout

I do that in dialog...

> alone and allows for redirections. However I wasn't satisfied with
> this solution either because of the remaining terminal interaction
> that resulted in screen flickering at startup and problems when executing
> SciTECO as a sub-process from other curses applications that do not
> expect terminal interaction.
>  
> > > I would also like to avoid relying on SIGINT delivery for
> > > interruptions by splitting
> > > the input loop in two threads: One with a wgetch() or getch() loop and
> > > the other one for executing
> > > SciTECO macros and doing all the remaining Curses work.
> > > Is it safe - with a non-threading ncurses build - to do that?
> > 
> > no - you would have to do _all_ of the ncurses work in one thread.
> >
> I expected something like this :-(.
> 
> The problem is: It's often not that easy. I have synchronous operations
> involving ncurses - doing them all in one thread (i.e. the UI thread)
> introduces a massive performance penalty due to synchronization and
> copying. But I'd have to see; the performance decrease might be
> smaller than anticipated since I also have a lot of operations that
> could be made asynchronous (i.e. the non-UI thread does not always have
> to wait for an answer).
> 
> But what's worse: Even then, I don't think it will work.
> How can the "worker" (non-UI) thread get the UI thread that is blocking
> on getch() to wake up and perform additional ncurses operations???
> AFAIK and according to getch(3NCURSES) there is no way to interrupt
> getch() via signals and no thread-safe function for inserting messages
> into the input FIFO that could be abused for turning getch() into
> an event loop. As long as the UI thread is blocking, it appears
> there is no way to safely call other curses functions.

agreed.
 
> Furthermore, ncurses (not to mention XOpen/curses) does not provide any
> way to separate its I/O from key processing which could be used
> to integrate curses into some kind of flexible event loop.
> 
> This leaves me with the following options:
> 
>  * Completely avoiding ncurses for input handling.
>    Given that an input fd is not required for ncurses to function
>    properly.
>    This obviously only works in ncurses/Unix.
>  * Using a threading-build of ncurses might help!?
>    But these builds are not provided by common Linux distributions.
>    Also it would be a ncurses-only solution.
>  * Polling input keys. I'm fearing the performance implications
>    of doing this a few thousand times a second, but doing it
>    every 100ms might be sufficient actually.
>    After all we're talking about __keyboard__ input and
>    asynchronous interruptions.
>    Problem with this is: Polling is not always straight forward.
>    E.g. sometimes I'm blocking waiting for some external process
>    to finish. But even there it would be possible.
> 
> So it seams that the best way to go would be relying on ^C and
> SIGINT on ncurses+Unix and providing a fallback on all other
> Curses platforms that uses nodelay() plus getch() polling every
> 100ms (or every n iterations) or so and my own keyboard input buffer.

...or communicating via a pipe to another process which handles input.
(still clumsy)

> > > This is esp. important for PDCurses builds (as there is currently no
> > > way to interrupt
> > > a long-running process) but I'm aware that PDCurses may behave
> > > completely different
> > > with regard to threading.
> > 
> > actually, I have not noticed any particular treatment of threading in
> > PDCurses (the same limitations may apply).
> >
> Me neither. I couldn't find a word about threading in the PDCurses
> documentation.

I'd have to read through the source code, but there's no mention of it
in the configure script, and the library doesn't have any relevant
externs.

-- 
Thomas E. Dickey <address@hidden>
http://invisible-island.net
ftp://invisible-island.net

signature.asc
Description: Digital signature