Re: Userspace module return value?
Ingo Molnar <[email protected]> Tue, 20 Jul 2004 16:50:28 +0200
| Newsgroups | gmane.network.tux |
|---|---|
| Message-ID | <[email protected]> |
* Marek Habersack <[email protected]> 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