>> Another option is to use newterm() in curses with a funopen()ed
>> stream for output which queues the output to be written
>> (nonblockingly) to the real stdout.
> Would toggling O_NONBLOCK using fcntl() work for you? A bit tedious,
> but it can be done "per operation".
...ish. I hadn't
On Thu, 30 Mar 2023, Mouse wrote:
Another option is to use newterm() in curses with a funopen()ed stream
for output which queues the output to be written (nonblockingly) to the
real stdout.
Would toggling O_NONBLOCK using fcntl() work for you? A bit tedious, but
it can be done "per
> You probably already researched this, but it looks like newterm() is
> in the curses library in NetBSD-5,
It is. (I wouldn't've even discovered it if it weren't. I started
looking at libcurses with an eye to providing some way to output data
via a callback instead of a file descriptor and
hello. You probably already researched this, but it looks like
newterm() is in the curses
library in NetBSD-5, so getting it to work in NetBSD-1.4T shouldn't be that
difficult.
-Brian
Hello. Yes, I realized the error I'd made after I sent you the e-mail.
I wonder if you
could utilize a pty to do what you need to get two different tty structures,
one blocking for
curses, and the other non-blocking?
-thanks
-Brian
>> [...non-blocking stdin vs stdout, with curses...]
> The only way I've thought of to work around this is to fork a helper
> process [...]
I just realized this is not quite true.
Another option is to use newterm() in curses with a funopen()ed stream
for output which queues the output to be
> I may be missing something in your curses non-blocking case, but
> can't you work around the issue by setting up an independent file
> descriptor, and hence tty structure, by performing a dup2(2) on stdin
> and then closing the original stdin file descriptor?
No. dup2, like dup, creates
hello. I may be missing something in your curses non-blocking case,
but can't you work
around the issue by setting up an independent file descriptor, and hence tty
structure, by
performing a dup2(2) on stdin and then closing the original stdin file
descriptor?
Then, of course, you can
>> I'm not sure whether I think it'd be better for O_NONBLOCK to apply
>> to the descriptor - [...]
> O_NONBLOCK should really be part of the _operation_, not the
> _object_. [...]
Agreed - or, at least, I agree that it should be possible to make it
part of the operation rather than of the
> Date: Thu, 30 Mar 2023 08:22:45 -0400 (EDT)
> From: Mouse
>
> I actually ran into a case where this distinction caused trouble. I
> have a program that uses curses for output but wants to do non-blocking
> input. So I set stdin nonblocking and threw fd 0 into the poll() loop.
>
> But, in
>> "They're per-open"
> That's not bad for this level of description.
Agreed!
>> ...which is not actually difficult to understand since it's the same
>> as the seek pointer behavior; that is, seek pointers are per-open
>> too.
> and almost all the other transient attributes, that is distinct
Date:Sun, 19 Mar 2023 07:05:52 +
From:David Holland
Message-ID:
| "They're per-open"
That's not bad for this level of description.
| ...which is not actually difficult to understand since it's the same
| as the seek pointer behavior; that is, seek
On Sun, Mar 19, 2023 at 01:49:54PM +0700, Robert Elz wrote:
> | Except they aren't. They're on open file table entries, something
> | remarkably difficult to describe in a way that doesn't just refer to
> | the kernel-internal mechanism behind it
>
> Yes. The terminology in this area
Date:Sat, 18 Mar 2023 19:46:17 -0400 (EDT)
From:Mouse
Message-ID: <202303182346.taa01...@stone.rodents-montreal.org>
| Except they aren't. They're on open file table entries, something
| remarkably difficult to describe in a way that doesn't just refer to
|
> Locks are on files, not file descriptors.
Except they aren't. They're on open file table entries, something
remarkably difficult to describe in a way that doesn't just refer to
the kernel-internal mechanism behind it (which for _this_ list isn't a
big deal, but...). If they were truly on
Date:Sat, 18 Mar 2023 11:32:37 -0400 (EDT)
From:Mouse
Message-ID: <202303181532.laa29...@stone.rodents-montreal.org>
| On examination, the manpages available to me (including the one at
| http://man.netbsd.org/flock.2) turn out to say nothing to clarify this.
I ran into an issue, which turned out to be, loosely put, that an open
file table entry cannot lock against itself. Here's a small test
program (most error checking omitted for brevity):
#include
#include
#include
#include
#include
#include
#include
static int fd;
int main(void);
int
17 matches
Mail list logo
