Is there a way to do a non-blocking net.TCPConn.Read() ?

[janosik]

The spec says that "The Windows implementation does not implement
SetTimeout".
Is there then any way to abort the read function while its waiting for
data?

[brainman]

On Dec 14, 7:27 pm, janosik <bimbek...@gmail.com> wrote:
> The spec says that "The Windows implementation does not implement
> SetTimeout".

It is the way current implementation works. Any improvements are
welcome.

> Is there then any way to abort the read function while its waiting for
> data?

I suppose, you could close the socket from another goroutine.

Alex

[janosik]

On Dec 14, 12:58 pm, brainman <alex.brain...@gmail.com> wrote:
> On Dec 14, 7:27 pm, janosik <bimbek...@gmail.com> wrote:
>
> > The spec says that "The Windows implementation does not implement
> > SetTimeout".
>
> It is the way current implementation works. Any improvements are
> welcome.

I wish I was competent enough to do so.

Currently I'm only trying to learn this language to see if it can be
useful for me.
It has such great and easy-to-use features, but sometimes misses a
basic functionality, like in this case: a lack of poll/select/toread
function.
Or another thing I've struggled with: try to parse a text file line-by-
line... terrible.
Why haven't they implemented os.File.ReadLine() ?

> > Is there then any way to abort the read function while its waiting for
> > data?
>
> I suppose, you could close the socket from another goroutine.

Tried that - it crashes.

[Corey Thomasson]

On 14 December 2010 09:03, janosik <bimb...@gmail.com> wrote:
>
>
> On Dec 14, 12:58 pm, brainman <alex.brain...@gmail.com> wrote:
>> On Dec 14, 7:27 pm, janosik <bimbek...@gmail.com> wrote:
>>
>> > The spec says that "The Windows implementation does not implement
>> > SetTimeout".
>>
>> It is the way current implementation works. Any improvements are
>> welcome.
>
> I wish I was competent enough to do so.
>
> Currently I'm only trying to learn this language to see if it can be
> useful for me.
> It has such great and easy-to-use features, but sometimes misses a
> basic functionality, like in this case: a lack of poll/select/toread
> function.

Why do you need to poll/select on sockets? why not just start a
goroutine for each connection and use channels to communicate where
necessary?

> Or another thing I've struggled with: try to parse a text file line-by-
> line... terrible.
> Why haven't they implemented os.File.ReadLine() ?

bufio.ReadBytes / bufio.ReadString are great for this

[Piotr2007]

On Dec 14, 3:08 pm, Corey Thomasson <cthom.li...@gmail.com> wrote:

> On 14 December 2010 09:03, janosik <bimbek...@gmail.com> wrote:
> > On Dec 14, 12:58 pm, brainman <alex.brain...@gmail.com> wrote:
> >> On Dec 14, 7:27 pm, janosik <bimbek...@gmail.com> wrote:
>
> >> > The spec says that "The Windows implementation does not implement
> >> > SetTimeout".
>
> >> It is the way current implementation works. Any improvements are
> >> welcome.
>
> > I wish I was competent enough to do so.
>
> > Currently I'm only trying to learn this language to see if it can be
> > useful for me.
> > It has such great and easy-to-use features, but sometimes misses a
> > basic functionality, like in this case: a lack of poll/select/toread
> > function.
>
> Why do you need to poll/select on sockets? why not just start a
> goroutine for each connection and use channels to communicate where
> necessary?

I am starting a goroutine and it gets stuck in the tcp read function.
While I would like to close the tcp connection and finish the routine
(when I decide to do so).

> > Or another thing I've struggled with: try to parse a text file line-by-
> > line... terrible.
> > Why haven't they implemented os.File.ReadLine() ?
>
> bufio.ReadBytes / bufio.ReadString are great for this

Oh, thank you!!
bufio.ReadString('\n') is exactly what I was looking for :)

[janosik]

Yeap. There is a goroutine and still no chance to solve it.
I mentioned poll/select because that's what I'd do in C.
Eventually some "set timeout" - would basically work the same way
anyway.
But how can I do it without any of these?

[Bill Burdick]

I don't know if gccgo works on Windows, but if it does, you can use it to roll your own socket library.

Bill

[brainman]

On Dec 15, 1:03 am, janosik <bimbek...@gmail.com> wrote:
> ...

> > I suppose, you could close the socket from another goroutine.
>
> Tried that - it crashes.

Care to demonstrate what happens with a small bit of code? Someone
might suggest a solution for you.

Alex

[Jessta]

On Wed, Dec 15, 2010 at 6:43 AM, janosik <bimb...@gmail.com> wrote:
> Yeap. There is a goroutine and still no chance to solve it.
> I mentioned poll/select because that's what I'd do in C.
> Eventually some "set timeout" - would basically work the same way
> anyway.
> But how can I do it without any of these?

Since there isn't a setTimeout() for the windows port yet, I guess
you'll have to wait until it's implemented or implement it yourself.
The windows port lags behind the *nix ports because the core
developers aren't windows developers.
But setTimeout() shouldn't be essential. In the rare case where the
other end of a connection maintains the connection while never sending
any data is not really something to worry about unless it's public
facing production code, which given the state of the windows port is
probably not recommended yet.

Go doesn't need poll/select because it already uses them under the
hood. A lot of the method calls that block a go-routine are
asynchronous calls to the system.
The Read() method you're using is using poll/select and is
non-blocking from the program's perspective, but is blocking from the
go-routine's perspective.

If you want to do other things while waiting for the Read() to
complete then launch more go-routines.

- jessta

--
=====================
http://jessta.id.au

[janosik]

On Dec 15, 12:42 am, Jessta <jes...@jessta.id.au> wrote:
> Since there isn't a setTimeout() for the windows port yet, I guess
> you'll have to wait until it's implemented or implement it yourself.
> The windows port lags behind the *nix ports because the core
> developers aren't windows developers.
> But setTimeout() shouldn't be essential. In the rare case where the
> other end of a connection maintains the connection while never sending
> any data is not really something to worry about

I need to disagree here. There is a lot to worry about because the
disconnect event is the very information that I must send to the other
end. And I am unable to do this when I want to.

Thanks to a friend that read this topic I got some experimental patch
which adds settimeout() functionality on Windows.
I still have some problems with it, but I'm willing to contribute into
fixing it by my own if I can only understand how it works.

So can anyone please tell me what the code below does? Because I
cannot find any "select { case:" in the documentation.

select {
case r = <-pckt.c:
case <-time.After(delta):
r = &ioResult{key: 0, qty: 0, errno: syscall.EWOULDBLOCK}
go func(pckt *ioPacket) {
<-pckt.c
}(pckt)
}

And here is the whole thing, if you need it:
http://codereview.appspot.com/1731047/patch/19001/20001

[peterGo]

janosik,

On Dec 15, 4:31 pm, janosik <bimbek...@gmail.com> wrote:
> I cannot find any "select { case:" in the documentation.

Select statements, The Go Programming Language Specification.
http://golang.org/doc/go_spec.html#Select_statements

Peter