Re: flock(2): locking against itself?

[Brett Lymn <blymn%internode.on.net@localhost>]

On Tue, Apr 18, 2023 at 10:40:24AM -0400, Mouse wrote:
> 
> Well, FSVO "dismissed".  It seems ridiculously heavyweight for the
> task; it also feels wrong.  Here, we have software that's crippled by
> lacking support for producing its output in a generalized fashion - so,
> rather than fixing the limitation, we depend on a heavyweight OS
> feature to work around it?  That's like, oh, say, we have a language
> that lacks support for decimal numbers, so, instead of fixing that, we
> add a front end which converts all numbers to octal or hex.
> 

Or we have a library that is specifically designed and implemented to
talk to a tty and optimaise the output so that it outputs the minimum
amount of data to that tty and now someone complains that it doesn't
work on something that is not a tty?

> Most briefly, I would prefer to fix the problem instead of just tacking
> on a workaround.
> 

I don't see a problem...

> For testing libcurses, the pty method is probably necessary, since you
> want to test the tty interface code as well.  But for testing just the
> screen updater (which I suspect is where most of the hair lies), why
> should you have to go through the kernel at all?  Make it a
> well-isolated unit and you can then unit-test it.
> 

No, it was more that it allowed testing of the curses library without
making extensive modifications to the internals and allow replication of
the expected execution environment.

Yes, the refresh code is the hairiest part of the code and was the
primary reason for writing the atf code.  This is the code that you will
be dealing with and it is deeply embedded.

> 
> I have two use cases already, and I have two more which are vulnerable
> to the same issue but which I haven't actually run into it with...yet.
> 

ok.

-- 
Brett Lymn
--
Sent from my NetBSD device.

"We are were wolves",
"You mean werewolves?",
"No we were wolves, now we are something else entirely",
"Oh"