Thanks, but that requires me to implement the code I would rather not have
to reinvent given that shells like Bash, Ksh, and Fish already have code to
do what I need. The problem is that those solutions are written in C and
C++ respectively rather than Go. While I consider myself an expert in C
(ha
On Sat, 2024-02-10 at 21:01 -0800, Kurtis Rader wrote:
> The only solution I can find that gets close to my requirements is
> https://github.com/ergochat/readline, but AFAICT it does not handle
> updates to the on-disk history file by concurrently executing
> processes.
There is also https://pkg.g
The only solution I can find that gets close to my requirements is
https://github.com/ergochat/readline, but AFAICT it does not handle updates
to the on-disk history file by concurrently executing processes.
On Sat, Feb 10, 2024 at 6:55 PM Kurtis Rader wrote:
> I'm looking for a package that wil
I'm looking for a package that will read/write a flat file database of
shell commands from multiple processes. I could take an existing
implementation in a different language, such as the one used by Bash or
Fish, and rewrite it in Go but was hoping someone has already done this.
The specific struc
Thank you, just save it before run. no correct answers anywhere.
On Wednesday, November 17, 2021 at 7:40:37 AM UTC+3 Francis wrote:
> Thank you all, CRTL + S , was the trick!.. I had a similar problem.
>
> On Thursday, April 20, 2017 at 12:45:07 AM UTC rame...@gmail.com wrote:
>
>> Thank you, Ni
Created a issue based on our discussion:
https://github.com/golang/go/issues/65653
On Saturday, February 10, 2024 at 10:49:58 PM UTC+1 Martin wrote:
> Hey Aldemar and Thomas,
>
> thanks for your hints.
>
> > While trying to upgrade a go package to 1.22.0 today, I ran into this
> same issue in m
Hey Aldemar and Thomas,
thanks for your hints.
> While trying to upgrade a go package to 1.22.0 today, I ran into this
same issue in my coverage step. From testing different combinations of
options for `go test`, it seems that the 'no such file or directory' errors
and resulting non-zero exit
Handling keep-alives on the *server* side doesn't require any sort of
connection pool. Just create one goroutine for each incoming TCP
connection, and once you've handled one request, loop around, waiting for
another request on the same connection.
(That's assuming the client does request use o
I can't see how a large number of waiting goroutines would cause an
increase in the number of OS threads, which was the OP's original problem
(hitting the 10,000 thread limit)
What the OP is implying - but we have not seen good evidence for yet - is
that in some circumstances a non-blocking con
