[DGD] Changing connect() (network package)

[Shentino]

On Jan 2, 2008 11:37 AM, Felix A. Croes <felix at dworkin.nl> wrote:
> Shentino <shentino at gmail.com> wrote:
>
> > > This works in DGD/MP (which knows about threads), but not in DGD
> > > (which doesn't).  It's not something you can solve with an #ifdef.
> >
> > Yes, I AM talking about MP injection of ER's.
> >
> > DGD is irrelevant.  SP DGD is so friggin simple on account of single
> > threadedness it would be trivial for someone to add whatever they feel
> > like.
>
> Not to me; and I want to have the same extension interface for both.
> Before you can create your execution round event, there has to be
> a networking event.  How shall DGD detect this and pass control to
> your extension?

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.

At any rate, in simple DGD, this could work as well:

X could simply set a flag and then DGD, if its select() call was
interrupted, could first check that flag before redoing the select(),
and if that flag is set, then call out to the extension.

The extension telling DGD it needs services, and DGD actually
responding to that request, are decoupled for the convenience of DGD.
Or MP.

I'm fairly confident that any MP specific stuff in a plain DGD
extension interface could be stubbed out or made a no-op.  As far as I
know, DGD is just a single processor case of DGD/MP

>
>
> >[...]
> > I concede that itimers may wreak havoc...unless of course I install my
> > own signal handler, which would simply alert MP that my extension
> > needs to inject an ER.  As long as I don't usurp any signals that MP
> > is already using (i.e. SIGPIPE, SIGTERM),
>
> Your signal handler will not prevent system calls from being
> interrupted, and DGD/MP is not using any signals.
>
>
> >[...]
> > As far as system call interruption, I have two answers for that:
> >
> > 1) As far as I know, you can tell the OS that you want to
> > automatically retry certain operations on a signal.
> > 2) I'd actually be surprised if properly written code would break from
> > getting an EINTR signal.  POSIX specs state that ANY system call can
> > return that, and official recommendations state that the operation
> > should be retried if it is still relevant.
>
> I'd appreciate it if you told me where the POSIX specification says
> that any system call can be interrupted by a signal, because I couldn't
> find it.  The POSIX specification does say:
>
>    System Interfaces 2.3 Error Numbers
>
>    For functions under the Threads option for which [EINTR] is not
>    listed as a possible error condition in this volume of IEEE Std
>    1003.1-2001, an implementation shall not return an error code of
>    [EINTR].
>
> And:
>
>    pthread_cond_timedwait, pthread_cond_wait
>
>    DESCRIPTION
>
>    ... If a signal is delivered to a thread waiting for a condition
>    variable, upon return from the signal handler the thread resumes
>    waiting for the condition variable as if it was not interrupted,
>    or it shall return zero due to spurious wakeup.
>
>    ERRORS
>
>    ... These functions shall not return an error code of [EINTR].
>
> Unfortunately, on some systems this is implemented as an aborted
> call on interrupt that you cannot distinguish from a normal return.
> Long live POSIX.

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.

Oh, that's right, you don't use signals, so EINTR would be impossible anyway.

..Or is it?

What about SIGTERM?  Doesn't that have the side effect of invoking a
call to driver-interrupt()?

Probably a corner case, but I did notice DGD's bootstrap code
installing a signal handler for SIGTERM.  And since it does no more
than cause a driver call to be injected (which implies arbitrary LPC
side handling semantics), it's pretty much a free-for-all to send a
SIGTERM to DGD.

Conceivably a badly timed SIGTERM could wreck DGD's logic just as
easily as any signal my extension could cause to be generated, so IMO
stray signals caused by my extension package wouldn't be causing any
problems that don't already exist.

You do make an interesting point about broken implementations.

>
> Now, I could try to work around this, but I'm not going to.  Or,
> I could offer my own non-signal itimer substitute for the benefit
> of the extension interface, but I'm not going to do that either.

If a SIGTERM can screw up DGD's execution by interrupting a system
call, then DGD already has a problem.

>
> Regards,
> Dworkin
>
> ___________________________________________
> https://mail.dworkin.nl/mailman/listinfo/dgd
>

Anyway, itimers was just an example of something BESIDES networking
that could make use of on-demand ER injection.  I figured I would
mention itimers because you have qualms about networking that are not
limited to being purely technical in nature, as evidenced by your
quite passionate comment of "Score another one against the networking
package".