On Tue, Jul 15, 2008 at 4:03 PM, Brian Aker <[EMAIL PROTECTED]> wrote: > Hi! > > On Jul 15, 2008, at 3:53 PM, MARK CALLAGHAN wrote: > >> Every time I read that code I get scared. But the code already uses >> non-blocking IO. From memory it does: >> 1) set socket options for non-blocking > > It flips this around and tests it frequently. I am also surprised that it > doesn't buffer automatically based on request. > > So to me these need to be set: > error= setsockopt(ptr->fd, SOL_SOCKET, SO_LINGER, > &linger, (socklen_t)sizeof(struct linger)); > error= setsockopt(ptr->fd, SOL_SOCKET, SO_SNDTIMEO, > &waittime, (socklen_t)sizeof(struct timeval)); > error= setsockopt(ptr->fd, SOL_SOCKET, SO_RCVTIMEO, > &waittime, (socklen_t)sizeof(struct timeval)); > (void)fcntl(ptr->fd, F_SETFL, flags | O_NONBLOCK); > > > Possibly: > error= setsockopt(ptr->fd, IPPROTO_TCP, TCP_NODELAY, > &flag, (socklen_t)sizeof(int)); > > AKA what we are doing in memcached today (which I have a lot more faith in > how it is working). > >> 2) try read/write and return if operation completes >> 3) set alarm >> 4) set socket options for blocking >> 5) retry read/write > > We can skip the alarms all together. There is no reason at all for them as > long as the IO is non-blocking, and I do not see a reason to do anything but > non-blocking IO. One thing is I need to find a good way of testing all of > this. Right now this stuff is wrapped up in VIO, but we do not have a need > for the abstraction any longer. I suspect a non-block call that did not > read "everything" could fail right now when it really could have passed.
You also don't need them if you want to do blocking with a timeout. You need to support the timeout somewhere to support the net_read_timeout/net_write_timeout semantics, or you need to get rid of those config values. If you only support non-blocking then you must add the code elsewhere. > > Cheers, > -Brian > > >> >> >> On Tue, Jul 15, 2008 at 3:43 PM, Brian Aker <[EMAIL PROTECTED]> wrote: >>> >>> Hi! >>> >>> Paul's observations in his blog yesterday on VIO using alarms caught my >>> attention. It has been a while since I looked at VIO and while it is a >>> back >>> burner debate I have always thought that it should behave more async like >>> then what it does today. >>> >>> To that end I am going to be removing the alarms bits around sockets and >>> just beefing it up to instead use non-block IO under the same manner that >>> we >>> did for libmemcached (and in memcached). Does anyone see why this should >>> be >>> optional? I can certainly see making the timeout optional but the use of >>> non-block just seems obvious. >>> >>> Any opinions? >>> >>> Cheers, >>> -Brian >>> >>> BTW from comments I think that alarm was added for mit-pthread... time >>> far >>> long ago before we had solid non-block across most platforms. >>> >>> -- >>> _______________________________________________________ >>> Brian "Krow" Aker, brian at tangent.org >>> Seattle, Washington >>> http://krow.net/ <-- Me >>> http://tangent.org/ <-- Software >>> _______________________________________________________ >>> You can't grep a dead tree. >>> >>> >>> >>> >>> _______________________________________________ >>> Mailing list: https://launchpad.net/~drizzle-discuss >>> Post to : [email protected] >>> Unsubscribe : https://launchpad.net/~drizzle-discuss >>> More help : https://help.launchpad.net/ListHelp >>> >> >> >> >> -- >> Mark Callaghan >> [EMAIL PROTECTED] > > -- > _______________________________________________________ > Brian "Krow" Aker, brian at tangent.org > Seattle, Washington > http://krow.net/ <-- Me > http://tangent.org/ <-- Software > _______________________________________________________ > You can't grep a dead tree. > > > > -- Mark Callaghan [EMAIL PROTECTED] _______________________________________________ Mailing list: https://launchpad.net/~drizzle-discuss Post to : [email protected] Unsubscribe : https://launchpad.net/~drizzle-discuss More help : https://help.launchpad.net/ListHelp
