ead.
> This won't be efficient in a tight loop, but if you know a point where may
> clients idle it may be worth it.
>
> //jb
>
> > On 6 Mar 2017, at 09:26, Nick Rio >
> wrote:
> >
> > The application is working right now. Current work for me
re - New Orleans LA
>
>
>
> *From:* golan...@googlegroups.com [mailto:
> golan...@googlegroups.com ] *On Behalf Of *Nick Rio
> *Sent:* 2017 March 06, Mon 02:26
> *To:* golang-nuts
> *Subject:* Re: [go-nuts] Re: How can I implement a TCP server using a
> model which simila
Hi Konstantin,
Thank you for the hit. I'll look into it.
On Monday, March 6, 2017 at 5:25:47 PM UTC+8, Konstantin Khomoutov wrote:
>
> On Mon, 6 Mar 2017 12:01:43 +0300
> Konstantin Khomoutov > wrote:
>
> > > The application is working right now. Current work for me is to
> > > found a way to
t;
>
> *From:* golan...@googlegroups.com [mailto:
> golan...@googlegroups.com ] *On Behalf Of *Nick Rio
> *Sent:* 2017 March 05, Sun 23:28
> *To:* golang-nuts
> *Subject:* [go-nuts] Re: How can I implement a TCP server using a model
> which similar to epoll (or kqueue, IOCP) rather than ju
Thank you for reply.
No guys, it's me using too many memories, not Goroutine.
However, I believe if I can make those code in epoll-style, I can then
build a task queue to handle those connections one by one in a queue when
they back to active. For example, start one *accepter* goroutine + few
