Re: flock(2): locking against itself?

2023-03-30 Thread Mouse
>> 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

Re: flock(2): locking against itself?

2023-03-30 Thread RVP
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

Re: flock(2): locking against itself?

2023-03-30 Thread Mouse
> 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

Re: flock(2): locking against itself?

2023-03-30 Thread Brian Buhrow
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

Re: flock(2): locking against itself?

2023-03-30 Thread Brian Buhrow
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

Re: flock(2): locking against itself?

2023-03-30 Thread Mouse
>> [...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

Re: flock(2): locking against itself?

2023-03-30 Thread Mouse
> 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

Re: flock(2): locking against itself?

2023-03-30 Thread Brian Buhrow
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

Re: flock(2): locking against itself?

2023-03-30 Thread Mouse
>> 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

Re: flock(2): locking against itself?

2023-03-30 Thread Taylor R Campbell
> 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

Re: flock(2): locking against itself?

2023-03-30 Thread Mouse
>> "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