8.2.3 - maybe a problem

[Robert Elz]

    Date:        Mon, 17 Jul 2000 01:27:37 -0700
    From:        Paul A Vixie <vixie at mibh.net>
    Message-ID:  <200007170827.BAA64217 at redpaul.mibh.net>

  | The problem is calling evGetNext() with EV_WAIT if needs!=0.

Sure, if that was happening, though it isn't, I think.

  | EV_WAIT on a nonbusy system can mean "wait for several minutes"

Fortunately, that's not a problem on munnari - if it waits tens of
milliseconds between packets, something has broken...

But, in general, yes, that would not be good.

  | Because BIND8's event system is
  | nonpreemptive, there's no clean way to code this.

But is there a need?

  | What that EV_POLL loop is trying to get at is all the
  | events which pertain to things handle_need() generates or consumes.

Like what?   handle_need() is just handling signals, right?  Those
things are async wrt packet arrivals anyway, so whether the needs are
handled before or after any particular packet, or timer, is entirely
arbitrary, whatever happens.

  | The inability of BIND8's event system to ensure fairness and avoid
  | starvation was one of the design forces behind BIND9's event system.

Sure.

  | So, I'm not going to get involved with the necessary rewrite of BIND8
  | since it's already been done and its name is BIND9.

I understand that.

  | I *think* the following will mostly work for munnari,

What I have now is just ...

        while (!main_needs_exit) {
                evEvent event;

                ns_debug(ns_log_default, 15, "main loop");
                if (needs != 0) {
#if 0
                        /* Drain outstanding events; handlers ~block~. */
                        while (evGetNext(ev, &event, EV_POLL) != -1)
                                INSIST_ERR(evDispatch(ev, event) != -1);
                        INSIST_ERR(errno == EINTR || errno == EWOULDBLOCK);
#endif
                        handle_need();
                } else if (evGetNext(ev, &event, EV_WAIT) != -1) {
                        INSIST_ERR(evDispatch(ev, event) != -1);
                } else {
                        INSIST_ERR(errno == EINTR);
                }
        }

If needs == 0, that's exactly as it was.  When needs != 0, it just
ignores the event queue, and handles the need instead.   That seems
to be working just fine.   No more zombies, and everythings seems to
be working just fine.  Only if I missed something, and handle_need()
really does depend upon something in the event queue being processed
first would that fail, and I couldn't see any reason that would be
true.   I certainly can't see that handing the first 42 events on the
queue is likely to make a material difference is it?  Munnari's queue
is likely to have hundreds of events pending (many hundreds).

But please don't bother making hack style fixes to keep munnari happy,
it is unlikely to run any new released version now anyway, what it
is now running seems fine.  Until I upgraded just a few weeks ago,
munnari was running 8.1.2-t3b or something of that approx vintage.
Once I find something that seems stable enough, I stick with it, since
all the other mods I do (the ones you don't want - like deleting all
that absurd name syntax checking code...) are too much work to be
doing every other week.

If a fix isn't going to be general enough for everyone, and generally
correct, then probably the code should be just left the way it has been,
which for most people is likely to keep working fine.

  | Yes, and yes.  evDo() can allocate memory, which means it cannot be called
  | from a signal handler on some systems, which is why we have a "needs" mask.

Sure.  Though I'm not sure the needs bit mask is really safe either, bit
setting is a rmw operation, which in theory means that the bit setting
and bit clearing can interfere with each other.  Technically I think
the signal handleers should just assign a const to a volatile int, that's
likely to be an autonomous operation, and safe (assuming the handler
correctly clears the var, and then handles the event of course).

I certainly didn't mean to do anything complex like evDo() in the
signal handlers, those should be more or less just like now.  But there's
no reason that evGetNext() couldn't notice that needs is set, and
create the event then, and link it onto the end of the list, is there?
That way the needs events would be being properly synchronised (whatever
that means in this context) with the other events.

But in any case, this is most likely more work than is justified now
for bind8, so unless doing this would be real easy, I'd just forget it.

kre