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