Re: [naviserver-devel] naviserver ChangeLog,1.787,1.788

[Stephen D. <sd...@gm...>]

On Fri, Aug 29, 2008 at 2:12 AM, Vlad Seryakov <vl...@cr...> wrote:
> And sent email without finishing the thought :-))
>
> Maybe parsing for range should done early enough and saved in the
> request, so whoever then will be sending data will use it.
>
> Just a thought from east coast :-))
>


Here's a couple of patches as a follow on to recent checkins to cvs:

  registerdriver.diff
  setlength.diff
  range-sendfile.diff

The first changes the prototype of the Driver callback. Actually it
removes it and adds a callback for each function: send, receive, keep,
close, and adds a new one: sendfile.

The second is just a clarification on the handling of length headers,
but it's needed for the third.

The third changes the range code to use the new sendfile support.  I
changed it round so that instead of saying SendRange you say
ParseRange. You pass it an array of Ns_FileVec's, it looks at the
headers and it fills it in for you.  I haven't tried, but this should
allow you to allocate an array of Ns_FileVec's and associate it with
the socket for the writer thread. We might have to also fixup the
timeout handling in the Ns_Sock* stuff -- It seems to always want to
do a poll timeout the way it's currently written.


I didn't want to check any of this in because the API change will
break half a dozen of your driver modules. So whenever you get a
chance (no rush) try out the registerdriver.diff patch and see if you
can get your modules working with it.

I did notice a couple of odd things. NsDriverClose() get called twice
for each socket. Not sure why, but I don't think it should. I've
changed the semantics: it used to be "Notify the driver that we are
going to close", now we delegate the close to the driver, which for
nssock is simply ns_sockclose().  The advantage is that for other
modules, like your nsudp, you should be able to handle whatever needs
to be handled. For example nsudp wants to keep the socket open.
Previously this was handled with special logic in the driver thread
checking for if UDP, else !UDP.  I think this complication is where
the DriverClose x2 bug crept in.

I haven't thoroughly checked it, but I'm 95% confident that you could
handle all the special cases for the current alternative drivers more
cleanly by delegating to the driver callbacks and removing all the
special logic to do with NS_DRIVER_* (UDP, UNIX, QUEUE_ONACCEPT,
QUEUE_ONREAD).  Have another look and see what you think.