[DGD] Changing connect() (network package)

[Felix A. Croes]

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?


>[...]
> 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.

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.

Regards,
Dworkin