diff options
Diffstat (limited to 'open_issues/select.mdwn')
| -rw-r--r-- | open_issues/select.mdwn | 458 |
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]]. |