On Saturday, December 21, 2019 at 11:33:15 AM UTC-8, Ian Lance Taylor wrote:
>
> On Sat, Dec 21, 2019 at 7:09 AM Daniel Eloff > wrote:
> >
> > Digging a little, it seems Go net poller uses edge triggered epoll on
> Linux. One of the harder considerations about using edge-triggered epoll is
> y
On Sat, Dec 21, 2019 at 7:09 AM Daniel Eloff wrote:
>
> Digging a little, it seems Go net poller uses edge triggered epoll on Linux.
> One of the harder considerations about using edge-triggered epoll is you have
> to read()/write() until EGAIN, otherwise you will not receive another
> read/wri
You can do something like this: https://play.golang.org/p/J7-N8_UDlL8
Le samedi 21 décembre 2019 17:23:28 UTC+1, Amarjeet Anand a écrit :
>
> Hi
> I have a set of strings(ASCII), that i want to assign to a string array(of
> cap 128).
> The position of the string in the array is decided by the ASC
Hi
I have a set of strings(ASCII), that i want to assign to a string array(of
cap 128).
The position of the string in the array is decided by the ASCII value of
the first char of the string.
Like...
strArr := [128]string{}
strA := "A string"
strB := "B string"
strArr[65] = strA // since strA star
Let me explain my situation.
I'm making a website and uses some very advanced functionality. It includes
a front-end wasm module, a daemon (written in GoLang), nginx configuration,
some PHP, and some haml, and sass. I have written a makefile to build
everything into 1) ELF binary (the daemon),
Digging a little, it seems Go net poller uses edge triggered epoll on
Linux. One of the harder considerations about using edge-triggered epoll is
you have to read()/write() until EGAIN, otherwise you will not receive
another read/write event for the socket when you call epoll_wait.
My question
You may be interested in this thread started by the Badger people:
https://groups.google.com/d/msg/golang-nuts/jPb_h3TvlKE/qdoHhxXeAwAJ
Apparently it can be used to increase the throughput of concurrent disk I/O
heavy programs.
Regards,
Didier.
On Thursday, December 5, 2019 at 10:51:50 AM UTC+
