[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Is a "silent" ncurses initialization possible?
Re: Is a "silent" ncurses initialization possible?
Mon, 8 Jun 2015 21:50:12 -0400
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.
> 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
> 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.
> > > 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
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
Thomas E. Dickey <address@hidden>
Description: Digital signature