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.
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.
_______________________________________________
Mailing list: https://launchpad.net/~drizzle-discuss
Post to : [email protected]
Unsubscribe : https://launchpad.net/~drizzle-discuss
More help : https://help.launchpad.net/ListHelp
