Userspace module return value?

[Marek Habersack]

On Tue, Jul 20, 2004 at 04:50:28PM +0200, Ingo Molnar scribbled:
> 
> * 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.
I see, one more question though:

Jul 20 16:45:47 localhost pch_mod[1750]: tux() returned -1
Jul 20 18:45:47 localhost kernel: Possibly unexpected TUX-thread exit(0) at c0117da3?
Jul 20 18:45:47 localhost kernel: TUX: thread 0 stopping ...
Jul 20 18:45:47 localhost kernel: TUX: thread 0 stopped.

What should I do when the tux() call itself returns -1? Do I return
TUX_RETURN_USERSPACE_REQUEST myself then since returning -1 seems to shut
the thread down?

thanks,

marek
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://listman.redhat.com/archives/tux-list/attachments/20040720/dbd26e53/attachment.sig>