tech-userlevel archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: flock(2): locking against itself?
>> (a) Does anyone have any other ideas, not mentioned above, for how
>> to address these issues?
> Not really, I would suggest using a pty even though you have
> dismissed it.
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.
Most briefly, I would prefer to fix the problem instead of just tacking
on a workaround.
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.
> The libcurses atf test does this to test curses functions, capturing
> the output and comparing it to an expected output. It uses poll(2)
> to check for i/o so as to prevent blocking on reads and writes.
But it needs an additional process, or at least thread, or it's
vulnerable to blocking when dealing with a large update. Even
heavierweight.
>> (b) Does anyone know of any work done towards pulling the screen
>> updater out of curses, so it can be used without all the baggage
>> tied to the OS that libcurses imposes?
> No. I am not really sure what general use it would be. Sure, you
> have a very specific need, that I can understand but struggle with a
> generalised concept.
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.
/~\ The ASCII Mouse
\ / Ribbon Campaign
X Against HTML mouse%rodents-montreal.org@localhost
/ \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
Home |
Main Index |
Thread Index |
Old Index