IRC.

1 files changed, 428 insertions, 30 deletions

diff --git a/open_issues/select.mdwn b/open_issues/select.mdwn
index 391509a9..caecc437 100644
--- a/open_issues/select.mdwn
+++ b/open_issues/select.mdwn
@@ -215,7 +215,7 @@ IRC, unknown channel, unknown date:
     <youpi> it's better than nothing yes
 
 
-# IRC, freenode, #hurd, 2012-07-21
+### IRC, freenode, #hurd, 2012-07-21
 
     <braunr> damn, select is actually completely misdesigned :/
     <braunr> iiuc, it makes servers *block*, in turn :/
@@ -315,7 +315,7 @@ IRC, unknown channel, unknown date:
       really easy and nice :-)
 
 
-## IRC, freenode, #hurd, 2012-07-22
+#### IRC, freenode, #hurd, 2012-07-22
 
     <braunr> antrik: you can't block in servers with sync ipc
     <braunr> so in this case, "select" becomes a request for notifications
@@ -379,7 +379,7 @@ IRC, unknown channel, unknown date:
       his reasoning (as does braunr)
 
 
-## IRC, freenode, #hurd, 2012-07-23
+#### IRC, freenode, #hurd, 2012-07-23
 
     <braunr> antrik: i was meaning sync in the most common meaning, yes, the
       client blocking on the reply
@@ -650,6 +650,9 @@ IRC, unknown channel, unknown date:
     <braunr> which is why i could choose time_value_t (a struct of 2 integer_t)
     <youpi> well, I'd say gnumach could grow a nanosecond-precision time value
     <youpi> e.g. for clock_gettime precision and such
+
+[[clock_gettime]].
+
     <braunr> so you would prefer me adding the time_spec_t time to gnumach
       rather than the hurd ?
     <youpi> well, if hurd RPCs are using mach types and there's no mach type
@@ -782,7 +785,7 @@ IRC, unknown channel, unknown date:
       API definition at RPC level too
 
 
-## IRC, freenode, #hurd, 2012-07-24
+#### IRC, freenode, #hurd, 2012-07-24
 
     <braunr> youpi: antrik: is vm_size_t an appropriate type for a c long ?
     <braunr> (appropriate mig type)
@@ -809,7 +812,7 @@ IRC, unknown channel, unknown date:
       continue
 
 
-## IRC, freenode, #hurd, 2012-07-25
+#### IRC, freenode, #hurd, 2012-07-25
 
     <antrik_> braunr: well, for actual kernel calls, machine-specific types are
       probably hard to avoid... the problem is when they are used in other RPCs
@@ -900,7 +903,7 @@ IRC, unknown channel, unknown date:
     <braunr> antrik: ah about that, ok
 
 
-## IRC, freenode, #hurd, 2012-07-26
+#### IRC, freenode, #hurd, 2012-07-26
 
     <pinotree> braunr: wrt your select_timeout branch, why not push only the
       time_data stuff to master?
@@ -914,7 +917,7 @@ IRC, unknown channel, unknown date:
     <braunr> i "only" have to adjust the client side select implementation now
 
 
-## IRC, freenode, #hurd, 2012-07-27
+#### IRC, freenode, #hurd, 2012-07-27
 
     <braunr> io_select should remain a routine (i.e. synchronous) for server
       side stub code
@@ -922,7 +925,14 @@ IRC, unknown channel, unknown date:
     <braunr> (since _hurs_select manually handles replies through a port set)
 
 
-## IRC, freenode, #hurd, 2012-07-28
+##### IRC, freenode, #hurd, 2013-02-09
+
+    <braunr> io_select becomes a simpleroutine, except inside the hurd, where
+      it's a routine to keep the receive and reply mig stub code
+    <braunr> (the server side)
+
+
+#### IRC, freenode, #hurd, 2012-07-28
 
     <braunr> why are there both REPLY_PORTS and IO_SELECT_REPLY_PORT macros in
       the hurd ..
@@ -941,7 +951,7 @@ IRC, unknown channel, unknown date:
     <braunr> i did something a bit ugly but it seems to do what i wanted
 
 
-## IRC, freenode, #hurd, 2012-07-29
+#### IRC, freenode, #hurd, 2012-07-29
 
     <braunr> good, i have a working client-side select
     <braunr> now i need to fix the servers a bit :x
@@ -998,7 +1008,7 @@ IRC, unknown channel, unknown date:
       queue ...
 
 
-## IRC, freenode, #hurd, 2012-07-30
+#### IRC, freenode, #hurd, 2012-07-30
 
     <braunr> hm nice, the problem i have with my hurd_condition_timedwait seems
       to also exist in libpthread
@@ -1096,7 +1106,7 @@ IRC, unknown channel, unknown date:
       (http://git.savannah.gnu.org/cgit/hurd/hurd.git/commit/?h=rbraun/select_timeout&id=40fe717ba9093c0c893d9ea44673e46a6f9e0c7d)
 
 
-## IRC, freenode, #hurd, 2012-08-01
+#### IRC, freenode, #hurd, 2012-08-01
 
     <braunr> damn, i can't manage to make threads calling condition_wait to
       dequeue themselves from the condition queue :(
@@ -1132,7 +1142,7 @@ IRC, unknown channel, unknown date:
     <braunr> it frightens me because i don't see any flaw in the logic :(
 
 
-## IRC, freenode, #hurd, 2012-08-02
+#### IRC, freenode, #hurd, 2012-08-02
 
     <braunr> ah, seems i found a reliable workaround to my deadlock issue, and
       more than a workaround, it should increase efficiency by reducing
@@ -1150,7 +1160,7 @@ IRC, unknown channel, unknown date:
       (/etc/hurd/runsystem i assume)
 
 
-## IRC, freenode, #hurd, 2012-08-03
+#### IRC, freenode, #hurd, 2012-08-03
 
     <braunr> glibc actually makes some direct use of cthreads condition
       variables
@@ -1302,7 +1312,7 @@ IRC, unknown channel, unknown date:
     <braunr> tests, reviews, more tests, polishing, commits, packaging
 
 
-## IRC, freenode, #hurd, 2012-08-04
+#### IRC, freenode, #hurd, 2012-08-04
 
     <braunr> grmbl, apt-get fails on select in my subhurd with the updated
       glibc
@@ -1324,7 +1334,7 @@ IRC, unknown channel, unknown date:
       and thomas d
 
 
-## IRC, freenode, #hurd, 2012-08-05
+#### IRC, freenode, #hurd, 2012-08-05
 
     <braunr> eh, i made dpkg-buildpackage use the patched c library, and it
       finished the build oO
@@ -1352,7 +1362,7 @@ IRC, unknown channel, unknown date:
       extremely large
 
 
-## IRC, freenode, #hurd, 2012-08-06
+#### IRC, freenode, #hurd, 2012-08-06
 
     <braunr> i have bad news :( it seems there can be memory corruptions with
       my io_select patch
@@ -1395,7 +1405,7 @@ IRC, unknown channel, unknown date:
 [[libpthread]].
 
 
-## IRC, freenode, #hurd, 2012-08-07
+#### IRC, freenode, #hurd, 2012-08-07
 
     <rbraun_hurd> anyone knows of applications extensively using non-blocking
       networking functions ?
@@ -1470,7 +1480,7 @@ IRC, unknown channel, unknown date:
       other for the servers, eh)
 
 
-## IRC, freenode, #hurd, 2012-08-07
+#### IRC, freenode, #hurd, 2012-08-07
 
     <braunr> when running gitk on [darnassus], yesterday, i could push the CPU
       to 100% by simply moving the mouse in the window :p
@@ -1490,7 +1500,7 @@ IRC, unknown channel, unknown date:
     <rbraunh> this linear search on dequeue is a real pain :/
 
 
-## IRC, freenode, #hurd, 2012-08-09
+#### IRC, freenode, #hurd, 2012-08-09
 
 `screen` doesn't close a window/hangs after exiting the shell.
 
@@ -1503,7 +1513,7 @@ IRC, unknown channel, unknown date:
 [[Term_blocking]].
 
 
-# IRC, freenode, #hurd, 2012-12-05
+### IRC, freenode, #hurd, 2012-12-05
 
     <braunr> well if i'm unable to build my own packages, i'll send you the one
       line patch i wrote that fixes select/poll for the case where there is
@@ -1512,7 +1522,7 @@ IRC, unknown channel, unknown date:
       timeout, doubling the total wait time when there is no event)
 
 
-## IRC, freenode, #hurd, 2012-12-06
+#### IRC, freenode, #hurd, 2012-12-06
 
     <braunr> damn, my eglibc patch breaks select :x
     <braunr> i guess i'll just simplify the code by using the same path for
@@ -1546,12 +1556,12 @@ IRC, unknown channel, unknown date:
     <braunr> this can account for the slowness of a bunch of select/poll users
 
 
-## IRC, freenode, #hurd, 2012-12-07
+#### IRC, freenode, #hurd, 2012-12-07
 
     <braunr> finally, my select patch works :)
 
 
-## IRC, freenode, #hurd, 2012-12-08
+#### IRC, freenode, #hurd, 2012-12-08
 
     <braunr> for those interested, i pushed my eglibc packages that include
       this little select/poll timeout fix on my debian repository
@@ -1560,7 +1570,7 @@ IRC, unknown channel, unknown date:
       regressions
 
 
-## IRC, freenode, #hurd, 2012-12-10
+#### IRC, freenode, #hurd, 2012-12-10
 
     <gnu_srs> I have verified your double timeout bug in hurdselect.c.
     <gnu_srs>  Since I'm also working on hurdselect I have a few questions
@@ -1631,7 +1641,13 @@ IRC, unknown channel, unknown date:
     <braunr> i'll try the non intrusive mode
 
 
-## IRC, freenode, #hurd, 2012-12-11
+##### IRC, freenode, #hurd, 2013-01-26
+
+    <braunr> ah great, one of the recent fixes (probably select-eintr or
+      setitimer) fixed exim4 :)
+
+
+#### IRC, freenode, #hurd, 2012-12-11
 
     <gnu_srs1> braunr: What is the technical difference of having the delay at
       io_select compared to mach_msg for one FD?
@@ -1641,7 +1657,7 @@ IRC, unknown channel, unknown date:
     <braunr> (for L4 guys it wouldn't be considered a slight optimization :))
 
 
-## IRC, freenode, #hurd, 2012-12-17
+#### IRC, freenode, #hurd, 2012-12-17
 
     <braunr> tschwinge:
       http://git.savannah.gnu.org/cgit/hurd/glibc.git/log/?h=rbraun/select_timeout_for_one_fd
@@ -1668,20 +1684,20 @@ IRC, unknown channel, unknown date:
       notifications resulting from the way io_select works
 
 
-## IRC, freenode, #hurd, 2012-12-19
+#### IRC, freenode, #hurd, 2012-12-19
 
     <braunr> tschwinge: i've tested the glibc rbraun/select_timeout_for_one_fd
       branch for a few days on darnassus now, and nothing wrong to report
 
 
-## IRC, freenode, #hurd, 2012-12-20
+#### IRC, freenode, #hurd, 2012-12-20
 
     <youpi> braunr: so, shall I commit the single hurd select timeout fix to
       the debian package?
     <braunr> youpi: i'd say so yes
 
 
-## IRC, freenode, #hurd, 2013-01-03
+#### IRC, freenode, #hurd, 2013-01-03
 
     <braunr> gnu_srs: sorry, i don't understand your poll_timeout patch
     <braunr> it basically reverts mine for poll only
@@ -1848,7 +1864,7 @@ IRC, unknown channel, unknown date:
       to the poll stuff: Have to check further with my poll patch...
 
 
-## IRC, freenode, #hurd, 2013-01-04
+#### IRC, freenode, #hurd, 2013-01-04
 
     <gnu_srs> Summary of the eglibc-2.13-38 issues: without the
       unsubmitted-setitimer_fix.diff patch and with
@@ -2037,6 +2053,388 @@ IRC, unknown channel, unknown date:
 See also [[alarm_setitimer]].
 
 
+#### IRC, freenode, #hurd, 2013-01-22
+
+    <gnu_srs> youpi: Maybe it's overkill to have a separate case for DELAY; but
+      it enhances readability (and simplifies a lot too)
+    <youpi> but it reduces factorization
+    <youpi> if select is already supposed to behave the same way as delay,
+      there is no need for a separate code
+    <gnu_srs> OK; I'll make a two-way split then. What about POLL and nfds=0,
+      timeout !=0?
+    <braunr> gnu_srs: handle nfds=0 as a pure timeout as the linux man page
+      describes
+    <braunr> it makes sense, and as other popular systems do it, it's better to
+      do it the same way
+    <braunr> and i disagree with you, factorization doesn't imply less
+      readability
+    <gnu_srs> So you agree with me to have a special case for DELAY?
+    <gnu_srs> Coding style is a matter of taste: for me case a: case b: etc is
+      more readable than "if then elseif then else ..."
+    <braunr> it's not coding style
+    <braunr> avoiding duplication is almost always best
+    <braunr> whatever the style
+    <braunr> i don't see the need for a special delay case
+    <braunr> it's the same mach_msg call
+    <braunr> (for now)
+    <braunr> gnu_srs: i'd say the only reason to duplicate is when you can't do
+      otherwise
+    <gnu_srs> ways of coding then... And I agree with the idea of avoiding code
+      duplication, ever heard of Literate Programming
+    <braunr> we'll need a "special case" when the timeout is handled at the
+      server side, but it's like two lines ..
+
+
+#### IRC, freenode, #hurd, 2013-02-11
+
+    <youpi> braunr: the libpthread hurd_cond_timedwait_np looks good to me
+
+
+##### IRC, freenode, #hurd, 2013-02-15
+
+    <youpi> braunr: does cond_timedwait_np depend on the cancellation fix?
+    <braunr> yes
+    <youpi> ok
+    <braunr> the timeout fix
+    <youpi> so I also have to pull that into my glibc build
+    <braunr> (i fixed cancellation too because the cleanup routine had to be
+      adjusted anyway
+    <braunr> )
+    <youpi> ah, and I need the patches hurd package too
+    <braunr> if unsure, you can check my packages
+    <youpi> ok, not for tonight then
+    <braunr> i listed the additional patches in the changelog
+    <youpi> yep, I'll probably use them
+
+
+#### IRC, freenode, #hurd, 2013-02-11
+
+    <youpi> braunr: I don't understand one change in glibc:
+    <youpi> - err = __io_select (d[i].io_port, d[i].reply_port, 0, &type);
+    <youpi> + err = __io_select (d[i].io_port, d[i].reply_port, type);
+    <braunr> youpi: the waittime parameter ahs been removed
+    <braunr> has*
+    <youpi> where? when?
+    <braunr> in the hurd branch
+    <youpi> in the defs?
+    <braunr> yes
+    <youpi> I don't see this change
+    <youpi> only the addition of io_select_timeout
+    <braunr> hum
+    <youpi> also, io_select_timeout should be documented along io_select in
+      hurd.texi
+    <braunr> be6e5b86bdb9055b01ab929cb6b6eec49521ef93
+    <braunr>     Selectively compile io_select{,_timeout} as a routine
+    <braunr>     * hurd/io.defs (io_select_timeout): Declare as a routine if
+    <braunr>     _HURD_IO_SELECT_ROUTINE is defined, or a simpleroutine
+      otherwise.
+    <braunr>     (io_select): Likewise. In addition, remove the waittime
+      timeout parameter.
+    <youpi> ah, it's in another commit
+    <braunr> yes, perhaps misplaced
+    <braunr> that's the kind of thing i want to polish
+    <braunr> my main issue currently is that time_data_t is passed by value
+    <braunr> i'm trying to pass it by address
+    <youpi> I don't know the details of routine vs simpleroutine
+    <braunr> it made sense for me to remove the waittime parameter at the same
+      time as adding the _HURD_IO_SELECT_ROUTINE macro, since waittime is what
+      allows glibc to use a synchronous RPC in an asynchronous way
+    <youpi> is it only a matter of timeout parameter?
+    <braunr> simpleroutine sends a message
+    <braunr> routine sends and receives
+    <braunr> by having a waittime parameter, _hurd_select could make io_select
+      send a message and return before having a reply
+    <youpi> ah, that's why in glibc you replaced MACH_RCV_TIMED_OUT by 0
+    <braunr> yes
+    <youpi> it seems a bit odd to have a two-face call
+    <braunr> it is
+    <youpi> can't we just keep it as such?
+    <braunr> no
+    <youpi> damn
+    <braunr> well we could, but it really wouldn't make any sense
+    <youpi> why not?
+    <braunr> because the way select is implemented implies io_select doesn't
+      expect a reply
+    <braunr> (except for the single df case but that's an optimization)
+    <braunr> fd*
+    <youpi> that's how it is already, yes?
+    <braunr> yes
+    <braunr> well yes and no
+    <braunr> that's complicated :)
+    <braunr> there are two passes
+    <braunr> let me check before saying anything ;p
+    <youpi> :)
+    <youpi> in the io_select(timeout=0) case, can it ever happen that we
+      receive an answer?
+    <braunr> i don't think it is
+    <braunr> you mean non blocking right ?
+    <braunr> not infinite timeout
+    <youpi> I mean calling io_select with the timeout parameter being set to 0
+    <braunr> so yes, non blocking
+    <braunr> no, i think we always get MACH_RCV_TIMED_OUT
+    <youpi> for me non-blocking can mean a lot of things :)
+    <braunr> ok
+    <braunr> i was thinking mach_msg here
+    <braunr> ok so, let's not consider the single fd case
+    <braunr> the first pass simply calls io_select with a timeout 0 to send
+      messages
+    <youpi> I don't think it's useful to try to optimize it
+    <youpi> it'd only lead to bugs :)
+    <braunr> me neither
+    <braunr> yes
+    <youpi> (as was shown :) )
+    <braunr> what seems useful to me however is to optimize the io_select call
+    <braunr> with a waittime parameter, the generated code is an RPC (send |
+      receive)
+    <braunr> whereas, as a simpleroutine, it becomes a simple send
+    <youpi> ok
+    <youpi> my concern is that, as you change it, you change the API of the
+      __io_select() function
+    <youpi> (from libhurduser)
+    <braunr> yes but glibc is the only user
+    <braunr> and actually no
+    <braunr> i mean
+    <braunr> i change the api at the client side only
+    <youpi> that's what I mean
+    <braunr> remember that io.Defs is almost full
+    <youpi> "full" ?
+    <braunr> i'm almost certain it becomes full with io_select_timeout
+    <braunr> there is a practical limit of 100 calls per interface iirc
+    <braunr> since the reply identifiers are request + 100
+    <youpi> are we at it already?
+    <braunr> i remember i had problems with it so probably
+    <youpi> but anyway, I'm not thinking about introducing yet another RPC
+    <youpi> but get a reasonable state of io_select
+    <braunr> i'l have to check that limit
+    <braunr> it looks wrong now
+    <braunr> or was it 50
+    <braunr> i don't remember :/
+    <braunr> i understand
+    <braunr> but what i can guarantee is that, while the api changes at the
+      client side, it doesn't at the server side
+    <youpi> ideally, the client api of io_select could be left as it is, and
+      libc use it as a simpleroutine
+    <youpi> sure, I understand that
+    <braunr> which means glibc, whether patched or not, still works fine with
+      that call
+    <braunr> yes it could
+    <braunr> that's merely a performance optimization
+    <youpi> my concern is that an API depends on the presence of
+      _HURD_IO_SELECT_ROUTINE, and backward compatibility being brought by
+      defining it! :)
+    <braunr> yes
+    <braunr> i personally don't mind much
+    <youpi> I'd rather avoid the clutter
+    <braunr> what do you mean ?
+    <youpi> anything that avoids this situation
+    <youpi> like just using timeout = 0
+    <braunr> well, in that case, we'll have both a useless timeout at the
+      client side
+    <braunr> and another call for truely passing a timeout
+    <braunr> that's also weird
+    <youpi> how so a useless timeout at the client side?
+    <braunr> 22:39 < youpi> - err = __io_select (d[i].io_port, d[i].reply_port,
+      0, &type);
+    <braunr> 0 here is the waittime parameter
+    <youpi> that's a 0-timeout
+    <braunr> and it will have to be 0
+    <youpi> yes
+    <braunr> that's confusing
+    <youpi> ah, you mean the two io_select calls?
+    <braunr> yes
+    <youpi> but isn't that necessary for the several-fd case, anyway?
+    <braunr> ?
+    <braunr> if the io_select calls are simple routines, this useless waittime
+      parameter can just be omitted like i did
+    <youpi> don't we *have* to make several calls when we select on several
+      fds?
+    <braunr> suure but i don't see how it's related
+    <youpi> well then I don't see what optimization you are doing then
+    <youpi> except dropping a parameter
+    <youpi> which does not bring much to my standard :)
+    <braunr> a simpleroutine makes mach_msg take a much shorter path
+    <youpi> that the 0-timeout doesn't take?
+    <braunr> yes
+    <braunr> it's a send | receive
+    <youpi> ok, but that's why I asked before
+    <braunr> so there are a bunch of additional checks until the timeout is
+      handled
+    <youpi> whether timeout=0 means we can't get a receive
+    <youpi> and thus the kernel could optimize
+    <braunr> that's not the same thing :)
+    <youpi> ok
+    <braunr> it's a longer path to the same result
+    <youpi> I'd really rather see glibc building its own private simpleroutine
+      version of io_select
+    <youpi> iirc we already have such kind of thing
+    <braunr> ok
+    <braunr> well there are io_request and io_reply defs
+    <braunr> but i haven't seen them used anywhere
+    <braunr> but agreed, we should do that
+    <youpi> braunr: the prototype for io_select seems bogus in the io_request,
+      id_tag is no more since ages :)
+    <braunr> youpi: yes
+    <braunr> youpi: i'll recreate my hurd branch with only one commit
+    <braunr> without the routine/simpleroutine hack
+    <braunr> and with time_data_t passed by address
+    <braunr> and perhaps other very minor changes
+    <youpi> braunr: the firstfd == -1 test needs a comment
+    <braunr> or better, i'll create a v2 branch to make it easy to compare them
+    <braunr> ok
+    <youpi> braunr: actually it's also the other branch of the if which needs a
+      comment: "we rely on servers implementing the timeout"
+    <braunr> youpi: ok
+    <youpi> -                 (msg.success.result & SELECT_ALL) == 0)
+    <youpi> why removing that test?
+    <youpi> you also need to document the difference between got and ready
+    <braunr> hm i'll have to remember
+    <braunr> i wrote this code like a year ago :)
+    <braunr> almost
+    <youpi> AIUI, got is the number of replies
+    <braunr> but i think it has to do with error handling
+    <braunr> and
+    <braunr> +                       if (d[i].type)
+    <braunr> +                         ++ready;
+    <youpi> while ready is the number of successful replies
+    <braunr> is what replaces it
+    <braunr> youpi: yes
+    <braunr> the poll wrapper already normalizes the timeout parameter to
+      _hurd_select
+    <braunr> no you probably don't
+    <braunr> the whole point of the patch is to remove this ugly hack
+    <braunr> youpi: ok so
+    <braunr> 23:24 < youpi> -                 (msg.success.result & SELECT_ALL)
+      == 0)
+    <braunr> when a request times out
+    <youpi> ah, right
+    <braunr> we could get a result with no event
+    <braunr> and no error
+    <braunr> and this is what makes got != ready
+    <youpi> tell that to the source, not me :)
+    <braunr> sure :)
+    <braunr> i'm also saying it to myself
+    <braunr> ... :)
+    <youpi> right, using io_select_request() is only an optimization, which we
+      can do later
+    <braunr> what i currently do is remove the waittime parameter from
+      io_select
+    <braunr> what we'll do instead (soon) is let the parameter there to keep
+      the API unchancged
+    <braunr> but always use a waittime of 0
+    <braunr> to make the mach_msg call non blocking
+    <braunr> then we'll try to get the io_request/io_reply definitions back so
+      we can have simpleroutines (send only) version of the io RPCs
+    <braunr> and we'll use io_select_request (without a waittime)
+    <braunr> youpi: is that what you understood too ?
+    <youpi> yes
+    <youpi> (and we can do that later)
+    <braunr> gnu_srs: does it make more sense for you ?
+    <braunr> this change is quite sparsed so it's not easy to get the big
+      picture
+    <braunr> sparse*
+    <braunr> it requires changes in libpthread, the hurd, and glibc
+    <youpi> the libpthread change can be almost forgotten
+    <youpi> it's just yet another cond_foo function :)
+    <braunr> well not if he's building his own packages
+    <youpi> right
+    <youpi> ok, apart from the io_select_request() and documenting the newer
+      io_select_timeout(), the changes seem good to me
+    <braunr> youpi: actually, a send | timeout takes the slow path in mach_msg
+    <braunr> and i actually wonder if send | receive | timeout = 0 can get a
+      valid reply from the server
+    <braunr> but the select code already handles that so it shouldn't be much
+      of a problem
+    <youpi> k
+
+
+##### IRC, freenode, #hurd, 2013-02-12
+
+    <braunr> hum
+    <braunr> io_select_timeout actually has to be a simpleroutine at the client
+      side :/
+    <braunr> grmbl
+    <youpi> ah?
+    <braunr> otherwise it blocks
+    <youpi> how so?
+    <braunr> routines wait for replies
+    <youpi> even with timeout 0?
+    <braunr> there is no waittime for io_select_timeout
+    <braunr> adding one would be really weird
+    <youpi> oh, sorry, I thought you were talking about io_select
+    <braunr> it would be more interesting to directly use
+      io_select_timeout_request
+    <braunr> but this means additional and separate work to make the
+      request/reply defs up to date
+    <braunr> and used
+    <braunr> personally i don't mind, but it matters for wheezy
+    <braunr> youpi: i suppose it's not difficult to add .defs to glibc, is it ?
+    <braunr> i mean, make glibc build the stub code
+    <youpi> it's probably not difficult indeed
+    <braunr> ok then it's better to do that first
+    <youpi> yes
+    <youpi> there's faultexec for instance in hurd/Makefile
+    <braunr> ok
+    <youpi> or rather, apparently it'd be simply user-interfaces
+    <youpi> it'll probably be linked into libhurduser
+    <youpi> but with an odd-enough name it shouldn't matter
+    <braunr> youpi: adding io_request to the list does indeed build the RPCs :)
+    <braunr> i'll write a patch to sync io/io_reply/io_request
+    <braunr> youpi: oh by the way, i'm having a small issue with the
+      io_{reply,request} interfaces
+    <braunr> the generated headers both share the same enclosing macro
+      (_io_user)
+    <braunr> so i'm getting compiler warning
+    <braunr> s
+    <youpi> we could fix that quickly in mig, couldn't we?
+    <braunr> youpi: i suppose, yes, just mentioning
+
+
+##### IRC, freenode, #hurd, 2013-02-19
+
+    <youpi> in the hurdselect.c code, I'd rather see it td[0]. rather than
+      td->
+    <braunr> ok
+    <youpi> otherwise it's frownprone
+    <youpi> (it has just made me frown :) )
+    <braunr> yes, that looked odd to me too, but at the same time, i didn't
+      want it to seem to contain several elements
+    <youpi> I prefer it to look like there could be several elements (and then
+      the reader has to find out how many, i.e. 1), rather than it to look like
+      the pointer is not initialized
+    <braunr> right
+    <youpi> I'll also rather move that code further
+    <youpi> so the preparation can set timeout to 0
+    <youpi> (needed for poll)
+    <youpi> how about turning your branch into a tg branch?
+    <braunr> feel free to add your modifications on top of it
+    <braunr> sure
+    <youpi> ok
+    <youpi> I'll handle these then
+    <braunr> youpi: i made an updated changelog entry in the
+      io_select_timeout_v3 branch
+    <youpi> could you rather commit that to the t/io_select_timeout branch I've
+      just created?
+    <braunr> i mean, i did that a few days ago
+    <youpi> (in the .topmsg file)
+    <youpi> ah
+    <youpi> k
+
+
+##### IRC, freenode, #hurd, 2013-02-26
+
+    <braunr> youpi: i've just pushed a rbraun/select_timeout_pthread_v4 branch
+      in the hurd repository that includes the changes we discussed yesterday
+    <braunr> untested, but easy to compare with the previous version
+
+
+##### IRC, freenode, #hurd, 2013-02-27
+
+    <youpi> braunr: io_select_timeout seems to be working fine here
+    <youpi> braunr: I feel like uploading them to debian-ports, what do you
+      think?
+    <braunr> youpi: the packages i rebuild last night work fine too
+
+
 # See Also
 
 See also [[select_bogus_fd]] and [[select_vs_signals]].