[DGD] Changing connect() (network package)

[Shentino]

On Jan 2, 2008 1:06 PM, Felix A. Croes <felix at dworkin.nl> wrote:
> Shentino <shentino at gmail.com> wrote:
>
> >[...]
> > DGD doesn't detect the networking event, the extension does.
> >
> > A new connection on my own port could generate a SIGIO or perhaps a
> > custom realtime signal, as specified by my extension when it invoked
> > open().  My extension would include a handler for that signal, and it
> > would handle it by X, where X is something that DGD would be watching
> > later.  Apart from an interrupted system call (which I deal with later
> > in this message), DGD wouldn't even be aware of what just happened.
> >
> > DGD would NOT pass control back to my extension until it was darn well
> > ready to.  DGD could legitimately be in the middle of some ER, or
> > housekeeping tasks, and naturally my extension has no business
> > interfering with that.  However, once DGD is done with its
> > housekeeping, calling back to the extension with a "ok, do your stuff"
> > is better.
> >
> > Sorta like that void (*endthread)() or whatever callback that the
> > extension interface already provides.
>
> This won't always work because a signal at the wrong time will not
> be seen until later.  When there is no normal network input, DGD
> will sleep until the next callout is due; when there is no callout
> and no input from connections, DGD will sleep forever.  An interrupt
> just before it starts that long wait will not be seen until whenever
> the next execution round completes.
>
> This is also true for the one signal that DGD responds to, SIGTERM.
> As you can see in the main loop, I could actually reduce the
> chance of this happening by moving the interrupt check to just
> before where user input is handled.
>
> Signals are hard to get working properly in a portable manner.
>
>
> >[...]
> > oops, guess I messed up.
> >
> > However, read() and family can, and your swap I/O code doesn't seem to
> > work around EINTR.  At least, if I've read the sources right.
>
> File system reads and writes are never interrupted.

I was pretty sure that's only true if its LOCAL to the machine.  But
what about a remotely mounted NFS?

And, say, a plain old read_file() from LPC?

What about named pipes?

I'll go back home tonight and double check the EINTR on read() and
write(), but I'm pretty sure certain circumstances are allowed to
cause EINTR on these calls.

>
>
> > Oh, that's right, you don't use signals, so EINTR would be impossible anyway.
>
> DGD/MP does not use signals, DGD does.

Hmm...

So, MP doesn't accept SIGTERM as an indication to call interrupt()?  Weird...