[9fans] two questions about go in Plan 9

[Francisco J Ballesteros]

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 proc does not report EOF to the other end
of the connection.

It might be something I made or something I didn't understand, but just in case
these are known I thought I might ask here.

thanks

[Matthew Veety]

Yeah I get those too. There are also some process spawning issues and UTF issues in http.

--
Veety

[Francisco J Ballesteros]

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 be able to interrupt it.
Now, in go on Plan 9, I can't interrupt it and I can't make the stream hangup.

What do you do in that case? Or, more likely, what am I doing wrong?

thanks

Post by Francisco J Ballesteros
Hi,
I've been using go for a few things in Plan 9, and noticed a couple of things.
- 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 proc does not report EOF to the other end
of the connection.
It might be something I made or something I didn't understand, but just in case
these are known I thought I might ask here.
thanks
[/mail/box/nemo/msgs/201302/876]

[l***@proxima.alt.za]

Post by Francisco J Ballesteros
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

[Nemo]

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.

Post by Francisco J Ballesteros
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
[/mail/box/nemo/msgs/201302/889]

[c***@gmx.de]

network connections on plan9 can be hanged up by writing "hangup" into
the corresponding ctl file.

--
cinap

[Francisco J Ballesteros]

I know, but, what's the std way to do that in go in plan 9?

Post by c***@gmx.de
network connections on plan9 can be hanged up by writing "hangup" into
the corresponding ctl file.
--
cinap
[/mail/box/nemo/msgs/201302/897]

[Matthew Veety]

That's how I do it usually.

Post by Francisco J Ballesteros
I know, but, what's the std way to do that in go in plan 9?

Post by c***@gmx.de
network connections on plan9 can be hanged up by writing "hangup" into
the corresponding ctl file.
--
cinap
[/mail/box/nemo/msgs/201302/897]

[Akshat Kumar]

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 ideas are welcome in this phase. We can try to
export a Hangup() function for Plan 9 for the Conn type
(or for individual implementations of the type).

Post by Francisco J Ballesteros
I know, but, what's the std way to do that in go in plan 9?

Post by c***@gmx.de
network connections on plan9 can be hanged up by writing "hangup" into
the corresponding ctl file.
--
cinap
[/mail/box/nemo/msgs/201302/897]

[Nemo]

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

Post by Akshat Kumar
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 ideas are welcome in this phase. We can try to
export a Hangup() function for Plan 9 for the Conn type
(or for individual implementations of the type).

Post by Francisco J Ballesteros
I know, but, what's the std way to do that in go in plan 9?

Post by c***@gmx.de
network connections on plan9 can be hanged up by writing "hangup" into
the corresponding ctl file.
--
cinap
[/mail/box/nemo/msgs/201302/897]

[/mail/box/nemo/msgs/201302/902]

[Skip Tavakkolian]

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.Close should write "hangup" to ctl and SetLinger could easily be
implemented (it returns EPLAN9 on the Go version I'm using -- tip from
a few days ago).

-Skip

Post by Nemo
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

Post by Akshat Kumar
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 ideas are welcome in this phase. We can try to
export a Hangup() function for Plan 9 for the Conn type
(or for individual implementations of the type).

Post by Francisco J Ballesteros
I know, but, what's the std way to do that in go in plan 9?

Post by c***@gmx.de
network connections on plan9 can be hanged up by writing "hangup" into
the corresponding ctl file.
--
cinap
[/mail/box/nemo/msgs/201302/897]

[/mail/box/nemo/msgs/201302/902]