Elsa MicroLink 33.6TQV on HP-UX 10.20 with vgetty

• Messages sorted by:[ date ][ thread ][ subject ][ author ]

Hi,

Umm wrote:
> On Wed, 3 Dec 1997, Gert Doering wrote:
> > > > I dimly remember that we have seen this on some other platform as well.
> > > > It seems to be related to setting VTIME to something > 0.
> > > > 
> > > > At that time, we did not fix it, because nobody had time (and partly
> > > > because I think that's a bug -- select() should return if there is 
> > > > *DATA*, not "if a subsequent read() won't block" - but then, select() 
> > > > isn't standardized *that* well...)
> > > actually select returns if the program receives a signal.
> > 
> > Huh? That may be true, but isn't relevant here. There are no signals in
> > this game.
> I tend to disagree with you, there are allways signals beyond our control.

Heh. We are trying to pin down a certain behaviour here. It occurs all
the time. Reliably. With nobody else messing around on that machine.

It is *not* caused by signals.

[..]
> Another thing, why have u choosed a UUCP style locking? was it a matter of
> compatibility with other software, or u prefer it instead of flock'ing it?

Standard. All programs have to agree upon something, and UUCP style
locking is very easily portable, and well established.

> If u could choose, would u go with UUCP style locking or flock???

UUCP style locking. If needed, you can do it by hand, you can easily 
detect stale locks, you can find out from the shell *who* is holding the
lock, etc.

flock, on the other side, is not portable, may not work over NFS, and
doesn't gain anything.

gert
-- 
USENET is *not* the non-clickable part of WWW!
           //www.muc.de/~gert/
Gert Doering - Munich, Germany      gert@greenie.muc.de
fax: +49-89-35655025    gert.doering@physik.tu-muenchen.de
.