[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
  Web www.spinics.net

Re: Userspace module return value?

* Marek Habersack <grendel@caudium.net> wrote:

> > > if (rval == REQ_STATIC) {
> > >     req->event = 1;
> > >     do_syslog("Static request, getting the object (%s)", req->objectname);
> > >     rval = tux(TUX_ACTION_GET_OBJECT, req);
> > >     if (rval < 0 || req->error) {
> > >       req->event = 2;
> > >       if (content_type(req) == CONTENT_NOTIFY) 
> > >         return send_failure(req, LOG_ERR_OBJECT_NOT_FOUND);
> > >       
> > >       goto abort;
> > >     }
> > >     return rval;
> > >   }
> > 
> > This code doesnt handle events properly. When tux() returns there might
> > be another request active (with a different ->priv value) - you need to
> > return so that your event loop can be re-called with the proper request
> > pointer.
> OK, I see the problem now. Above, I'm calling
> tux(TUX_ACTION_GET_OBJECT, req) and if it fails I immediately call
> either tux(TUX_ACTION_SEND_BUFFER, req) or
> tux(TUX_ACTION_FINISH_CLOSE_REQ, req) (in the 'abort; label) - instead
> I should return immediately after the TUX_ACTION_GET_OBJECT call fails
> and send the buffer or close the connection only the next time
> handle_events is called. Did I get it right?

almost, with the following qualifications: the tux() call cannot 'fail'.

req->error after a tux() call might be for another request, in a
completely different state - that is not a result of the tux() call you
just did. So you should always return after doing a tux() call, and let
Tux restart your event loop.

(alternatively you could also loop yourself and only return if you see a
non-TUX_RETURN_USERSPACE_REQUEST return code from the tux() call - but
it's more readable to just return - the daemon will re-call your
module's event loop immediately. Check out tux.c of the Tux userspace
source code.)

generally i'd suggest to shape your event loop like the demo modules do:
switch(req->event), and try to return as early as possible when doing a
tux() call. Most demo modules do a 'return tux(...);' to finish an event
and drive the state-machine forward.


[Older Fedora Users Mail]     [Home]     [Fedora Legacy]     [Fedora Desktop]     [iPod Nano]     [ATA RAID]     [Fedora Bible]     [Fedora Marketing]     [Fedora Mentors]     [Fedora Packaging]     [Fedora SELinux]     [Big List of Linux Books]     [Yosemite News]     [Yosemite Photos]     [KDE Users]     [Fedora Tools]     [Fedora Docs]

Powered by Linux

  Web www.spinics.net