spinning bug

[Brad Fitzpatrick]

[ moved to mailing list ]

But, how do we tell libevent we want edge-triggered?  If we do it
ourselves, how do we get libevent's current mode?

Should we fork libevent and include it in memcached?  (perfectly legal,
but questionably immoral)

- Brad


On Tue, 26 Aug 2003, Anatoly Vorobey wrote:

> I'm still racking my brains over this bug, and coming up with nothing
> all the time. I have one new crazy idea though.
>
> Look. We suspect that the spinning bug occurs because some
> event starts signalling all the time, and our state machine
> doesn't know how to satisfy it, so it keeps signalling, stealing
> CPU time. Right?
>
> But what if we go from level-triggered epoll to edge-triggered? IIRC,
> the only difference between them is this:
>
>     if you get a read event and don't read all the data, you won't
>     get the signal ever again after you return.
>
> But we always *do* read the data all the way... don't we? We don't
> give up and return until we get a result from read() saying we have
> nothing else to read (or we go into write mode, of course... but when we
> eventually come out of that, we go into the read mode and attempt
> read()ing right away w/o relying on being signalled first).
>
> So, IIRC, by just going into edge-triggered mode we can make the
> spinning problem disappear. The "runaway" event won't signal more than
> once if we don't handle it, which we apparently don't. Does this sound
> logical to you?
>
> (level-triggered epoll can do edge-triggered as well, so we don't have
> to change the patches... just add an ioctl call or whatever)
>
> --
> avva
>
>