will do, it may take a while Stephen Deasey wrote: > On Fri, Aug 29, 2008 at 2:12 AM, Vlad Seryakov <[EMAIL PROTECTED]> 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. > > > ------------------------------------------------------------------------ > > ------------------------------------------------------------------------- > This SF.Net email is sponsored by the Moblin Your Move Developer's challenge > Build the coolest Linux based applications with Moblin SDK & win great prizes > Grand prize is a trip for two to an Open Source event anywhere in the world > http://moblin-contest.org/redirect.php?banner_id=100&url=/ > > > ------------------------------------------------------------------------ > > _______________________________________________ > naviserver-devel mailing list > naviserver-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/naviserver-devel
------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ naviserver-devel mailing list naviserver-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/naviserver-devel
