i think linux and windows both distinguish between allowing io to
complete or not via shutdown() and close() respectively (close causes
a RST instead of FIN).
if my understanding is correct, then: netFD.CloseRead and CloseWrite
for Plan 9 will work by just closing the ctl and data fd's;
netFD.Clo
yes. that was the problem.
perhaps exporting hangup would be
fine.
or perhaps a close in a tcp stream
should also interrupt the reader in
plan9, if any.
thanks
On Feb 18, 2013, at 7:58 PM, aku...@mail.nanosouffle.net wrote:
> In order to deal with Conn types, you're supposed to just
> use t
In order to deal with Conn types, you're supposed to just
use the interface's functions. Unfortunately, Conn's
Close() simply closes the associated fd. I think in general,
this is fine. For the Listener, a Close() will do the hangup.
I'm updating the net package implementation for Plan 9,
so new i
That's how I do it usually.
On Feb 18, 2013, at 13:12, Francisco J Ballesteros wrote:
> I know, but, what's the std way to do that in go in plan 9?
>
> On Feb 18, 2013, at 7:07 PM, cinap_len...@gmx.de wrote:
>
>> network connections on plan9 can be hanged up by writing "hangup" into
>> the co
I know, but, what's the std way to do that in go in plan 9?
On Feb 18, 2013, at 7:07 PM, cinap_len...@gmx.de wrote:
> network connections on plan9 can be hanged up by writing "hangup" into
> the corresponding ctl file.
>
> --
> cinap
>
> [/mail/box/nemo/msgs/201302/897]
network connections on plan9 can be hanged up by writing "hangup" into
the corresponding ctl file.
--
cinap
not really. in some cases a server I
have wants to close the con to a
client and there's a reader proc.
I would like to hang up even if the
client doesn't.
On Feb 18, 2013, at 5:54 PM, lu...@proxima.alt.za wrote:
>> What do you do in that case? Or, more likely, what am I doing wrong?
>
> You'
> What do you do in that case? Or, more likely, what am I doing wrong?
You're trying to signal in-band, which is only a short cut. Would it
be expensive to put the signalling out of band?
++L
Forgive me,
Somehow I removed the -v from the call to go test. That makes the log print
only for failed tests.
Regarding TCP, forsyth reminded me that it's what I'd get with the std. Plan 9
system calls, which
is so.
I guess my question is… how can I interrupt a reader in that case? In C I'd
Yeah I get those too. There are also some process spawning issues and UTF
issues in http.
--
Veety
Hi,
I've been using go for a few things in Plan 9, and noticed a couple of things.
I'd just like to know if it's me or if this also happens to others:
- diagnostics issued by log.Print et al. don't show up unless I call log.Fail
- closing a tcp connection which is still open by a nearby reader pr
11 matches
Mail list logo
