[DGD] Changing connect() (network package)

[Felix A. Croes]

Shentino <shentino at gmail.com> wrote:

> > Have you ever tried to interrupt a command running on a networked
> > filesystem that hung?
>
> Not really, but if the OS decides to issue an EINTR (linux can be
> configured this way, for instance), the command should handle that.
> Simple, oneshot commands can simply quit and require manual retry.

Ah, I see NFS has "improved" since the good old days :-)

However, there won't be anything to retry.  The EINTR will only be
issued when the filesystem is unresponsive, i.e. hangs.  What do you
want DGD to do when it cannot access the filesystem, write "Sorry"
to all telnet connections?


> But something like DGD doesn't answer too well with simply being
> rerun.  If the OS issues an EINTR in this case, then DGD should just
> try again instead of letting an interrupted system call throw it off.
> Especially if the cause of the hang can be remedied, there's no need
> for DGD to go belly up on account of an EINTR that was itself induced
> by a temporary condition that itself could be fixed.
>
> Suppose that DGD is just booting up, and it's reading driver.c over
> NFS, and due to horrendous latency, the OS that DGD is running on
> times out (gets tired of waiting), and instead of getting an I/O
> error, an EINTR is returned?

That only happens if the NFS share is mounted with the proper option,
the filesystem hangs, and a signal is delivered to the process.  If
you kill something, you want it dead.


> I think that object compilation during bootup should at least be
> checking for EINTR, even if nothing else is.
>
> NFS can cause EINTR at least with linux.  I dunno about other OS's,
> but simply ignoring EINTR would have the side effect of outlawing
> anything other than local file access.

Go out in the real world, look at some source code and see how it
deals with EINTR in a normal filesystem read/write.

Regards,
Dworkin