Userspace module return value?
Ingo Molnar
mingo at elte.hu
Tue Jul 20 14:50:28 UTC 2004
* Marek Habersack <grendel at 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.
Ingo
More information about the tux-list
mailing list