From: Alexandre F. <ale...@gm...> - 2007-02-27 00:34:36
|
On 2/26/07, Andreas Leitgeb <av...@lo...> wrote: > > ... this means, that wherever I previously passed one socket > (or bidirectional pipe) to a proc, I'd now have to pass both > ends spearately, if "at a later time" I might need to close > the write side only. Oh yes. Just like when you pass a pair of fds when handling a pipe at the C level. You just have two int members in a larger struct instead of one. Is this a problem ? And when you say "pass both ends", it is a bit of an exaggeration, since most routines will use only one of the sides. Only creators/destructors really care about the pair. > If instead I defer splitting to the point > where I need it splitted, I'm back faced with re-registering > the read-fileevents. Well if you really want to use this hammer, I won't interfere :-) > I find this still a very ugly idiom, when all that is really > needed was a way to finish just the write-side of a channel. Indeed my initial request (years ago) was a [close -write]. But what I like in the splitting approach, is that it may spawn other interesting evolutions, like setting differently a fconfigure flag on either side (like -blocking or -translation). And yes, this is even possible for sockets via dup(). > ... complicated ref-count maintaining > for the involved OS ressources and a need to take care of > explicit, but (on user's pov) *ineffective* closing of the > original handle I agree this part is a bit unsatisfactory. But it could be fixed, say, by deciding that [chan split] operates destructively: foreach {r w} [chan split $ch] break; # <-- $ch gets invalidated, aka "closed" This way you just need 2 separate closes (not 3). > I'd prefer if we did the half-close now, and only if there is > really a need, we can introduce channel-splitting later (e.g. > somewhere after 2038-01-19 03:14:07 :-) :-) > Iow., splitting channels might be a usable thing, but it is > only a very clumsy solution to the problem at hand. In fact I don't really care. My above arguments are merely aesthetic. I'm ready to lean either way, and I agree with you that getting something implemented reasonably soon would be better than crafting a silver bullet for Tcl 10. Best regards, -Alex |