bagder: curl-www/libcurl/hiper _schedule.html,1.19,1.20

Update of /cvsroot/curl/curl-www/libcurl/hiper
In directory labb:/tmp/cvs-serv10711

Modified Files:
	_schedule.html 
Log Message:
today's actions


Index: _schedule.html
===================================================================
RCS file: /cvsroot/curl/curl-www/libcurl/hiper/_schedule.html,v
retrieving revision 1.19
retrieving revision 1.20
diff -u -d -r1.19 -r1.20
--- _schedule.html	22 Dec 2005 08:53:59 -0000	1.19
+++ _schedule.html	22 Dec 2005 16:08:39 -0000	1.20
@@ -33,6 +33,40 @@
 
 <table class="news">
 
+MARKDATE(Dec 22 2005) I can now properly run tests with several hundred
+ connections using curl_multi_socket() and it works. The lack of timeout
+ support of course hampers it but my test case doesn't reveal this. At the
+ moment, a single call to curl_multi_socket() on an active and readable
+ connection seems to average around 7 usec.
+<p>
+ I'm a bit disturbed that select() is acting up on me. When I set a huge
+ amount of bits in the read and write sets, and call select() it can return a
+ value that is <i>not</i> the same amount of bits set in the read and write
+ sets as I'm pretty sure it is designed and documented to do. Also, it seems
+ to set bits in the writable set for sockets I didn't ask to get checked for
+ writability, so in my "libevent-emulation" I now need to only check sockets
+ for write readiness if libcurl has specifically asked for it as otherwise we
+ call curl_multi_socket() too often...
+<p>
+ I'm (yet again) having second thoughts on how to deal with the timeouts. I
+ want to avoid having to call the callbacks and update the timeout on all
+ sockets and I don't want the timeout to be socket-based since there might be
+ more than one socket for a single easy handle and I'd then rather just call
+ curl_multi_socket() once and have that sort out what sockets to use. At the
+ same time it seems that libevent has its timeouts on a per-socket basis (not
+ surprisingly really) so if I don't do them per-socket, how are we gonna use
+ libevent (etc) efficiently? Then of course, there's a separate timer
+ mechanism in libevent that might be useful.
+<p>
+ <a href="hiper-3.patch">hiper-3.patch</a> is now at 60K. Make sure you apply
+ it to a fresh CVS, it is not applying cleanly to 7.15.1... I did commit parts
+ of my work, to make it easier to point out web versions of the docs for the
+ new functions. See <a
+ href="/libcurl/c/curl_multi_socket.html">curl_multi_socket()</a> and <a
+ href="http://daniel.haxx.se/projects/c-ares/ares_getsock.html">ares_getsock()</a>.
+
+STOP
+
 MARKDATE(Dec 21 2005) Regarding the time-outs, I think I'll just make sure
 that libcurl keeps a I-want-to-get-called-no-later-than-this time ("last
 time") for each easy handle, and then the callback will be called with a