Re: [9fans] two questions about go in Plan 9

Re: [9fans] two questions about go in Plan 9

[Francisco J Ballesteros]

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_lenrek@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]

Re: [9fans] two questions about go in Plan 9

[Matthew Veety]

That's how I do it usually.

On Feb 18, 2013, at 13:12, Francisco J Ballesteros <nemo@lsub.org> 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_lenrek@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]
>
>

Re: [9fans] two questions about go in Plan 9

[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).

On 18 February 2013 10:12, Francisco J Ballesteros <nemo@lsub.org> 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_lenrek@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]
>
>

Re: [9fans] two questions about go in Plan 9

[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

On Feb 18, 2013, at 7:58 PM, akumar@mail.nanosouffle.net wrote:

> 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).
>
> On 18 February 2013 10:12, Francisco J Ballesteros <nemo@lsub.org> 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_lenrek@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]
>
> [/mail/box/nemo/msgs/201302/902]

Re: [9fans] two questions about go in Plan 9

[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

On Mon, Feb 18, 2013 at 11:04 AM, Nemo <nemo@lsub.org> wrote:
> 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, akumar@mail.nanosouffle.net wrote:
>
>> 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).
>>
>> On 18 February 2013 10:12, Francisco J Ballesteros <nemo@lsub.org> 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_lenrek@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]
>>
>> [/mail/box/nemo/msgs/201302/902]
>

Re: [9fans] two questions about go in Plan 9

[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.

On Feb 18, 2013, at 5:54 PM, lucio@proxima.alt.za wrote:

>> 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]

Re: [9fans] two questions about go in Plan 9

[cinap_lenrek]

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

--
cinap

Re: [9fans] two questions about go in Plan 9

[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


On Feb 18, 2013, at 4:07 PM, nemo@lsub.org wrote:

> 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 
> 
> 
> [/mail/box/nemo/msgs/201302/876]

Re: [9fans] two questions about go in Plan 9

[lucio]

> 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

[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 

Re: [9fans] two questions about go in Plan 9

[Matthew Veety]

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

--
Veety