The docs:“ A single goroutine runs all finalizers for a program, sequentially. If a finalizer must run for a long time, it should do so by starting a new goroutine.”So the code did not follow the api docs - as apparently the close() is indefinite. On Mar 19, 2025, at 6:46 AM, Gavra wrote:Yes, I i
Thanks Michael.
My opinion is
1. It should be mentioned explicitly in the doc that a blocking finalizer
will cause future objects with finalizers to leak. Probably next to the "A
single goroutine runs all finalizers for a program..." section.
2. Go should provide a way to know about it when it ha
On Wednesday, 19 March 2025 at 09:55:58 UTC Gavra wrote:
This finalizer blocks the runtime's finalizer goroutine
Out of interest, what made it block? Was the finalizer doing some channel
communication, for example?
--
You received this message because you are subscribed to the Google Groups
> On Mar 19, 2025, at 5:34 PM, Robert Engels wrote:
>
> I suspect if you wrote a small real world parser you would find a negligible
> performance difference.
I am writing a real-world parser. I'll benchmark it when I am done.
-Mike
--
You received this message because you are subscribed t
Hi Mike,
I don't know what quirk of human nature is that causes
so many to want to change a language to fit their whims, when
that language has as a principal virtue that it wants to be super readable
and almost never change (visit C++ for a strong argument
as to Go's posture is so beneficial;
I suspect if you wrote a small real world parser you would find a negligible
performance difference.
I’ll look for one on GitHub.
> On Mar 19, 2025, at 3:24 PM, Mike Schinkel wrote:
>
>
>>
>> On Mar 19, 2025, at 1:55 PM, Ian Lance Taylor wrote:
>>
>>> On Wed, Mar 19, 2025 at 10:43 AM Mi
> On Mar 19, 2025, at 8:18 PM, Jason E. Aten wrote:
> You reach for super simple code, maybe codedgen that allows
> inlining,
There are definitely code generators that exist for lexers and parsers —
Pigeon, goyacc, Gocc, Textmapper, etc. — and those are great projects in their
own right.
But
https://github.com/hirochachacha/go-smb2/blob/c8e61c7a5fa7bcd1143359f071f9425a9f4dda3f/client.go#L1063
We are looking for why exactly it blocked (probably incorrect ctx) but I
think this close should run in a goroutine.
On Wednesday, 19 March 2025 at 12:29:34 UTC+2 Brian Candler wrote:
> On Wedn
In fact the code you reference - the close() - does things the Go docs warn specifically not to do. You may be better off using runtime.AddCleanup()On Mar 19, 2025, at 6:32 AM, Robert Engels wrote:In principle, I would argue that there is a correctness problem. You should not rely on finalizers e
Yes, I intend to open a bug for them.
I agree that one should not relay on the execution of finalizers. But, the
fact that the runtime just piles them up because one package did wrong is
outrageous.
By the way, I am not sure why but I can see the mfinal routine only when
running my program fro
Hey,
We finally figured it all out.
The cause to the leak is a bug in a finalizer that is unrelated to sqlite3.
This finalizer blocks the runtime's finalizer goroutine, leading to objects
with finalizers to leak.
We find it very surprising that the runtime does nothing to warn about
this. Especi
Yes, even if it was only a few ms, they should have run it in a goroutine.
On Wednesday, 19 March 2025 at 14:17:56 UTC+2 Robert Engels wrote:
> The docs:
>
> “ A single goroutine runs all finalizers for a program, sequentially. If
> a finalizer must run for a long time, it should do so by starti
On Wed, Mar 19, 2025 at 8:46 PM Gavra wrote:
> Yes, I intend to open a bug for them.
> I agree that one should not relay on the execution of finalizers. But, the
> fact that the runtime just piles them up because one package did wrong is
> outrageous.
>
> By the way, I am not sure why but I can s
Sorry you ran into this issue.
Unfortunately, this is pretty much how such features tend to be designed to
keep overheads low. You make a good point that we should have more
diagnostics to detect when this happens. We can add a `runtime/metrics`
metric, or perhaps add extend the capabilities of
> On Mar 18, 2025, at 8:40 PM, Ian Lance Taylor wrote:
>
> On Tue, Mar 18, 2025 at 4:51 PM Mike Schinkel wrote:
>>
>> While working on a parser, I've repeatedly encountered patterns like:
>>
>> if c == ' ' || c == '\t' { /* handle whitespace */ }
>> if token == EOL || token == EOF { /* han
If you haven't seen it, this is a great read on
coroutines (uses, advantages, disadvantages, design
of systems, integration with threading systems, reification,
real-world examples in network protocols like SSH ...)
by the brilliant Simon Tatham of PuTTY fame.
https://www.chiark.greenend.org.uk/~s
> Unfortunately, this is pretty much how such features tend to be designed
to keep overheads low.
Er, sorry, this is actually a little more nuanced. Creating a new goroutine
for each finalizer/cleanup could cause a different problem of generating
too many goroutines (so, too much memory being
> On Mar 19, 2025, at 1:55 PM, Ian Lance Taylor wrote:
>
> On Wed, Mar 19, 2025 at 10:43 AM Mike Schinkel wrote:
>>
>> Given these benchmark results, would the Go team reconsider such a language
>> feature on a basis of performance vs. a comparison of syntax to bring if
>> statement performan
Filed https://github.com/golang/go/issues/72948,
https://github.com/golang/go/issues/72949,
and https://github.com/golang/go/issues/72950 to track the suggested
improvements.
On Wednesday, March 19, 2025 at 9:52:17 AM UTC-4 Gavra wrote:
Thanks Michael.
My opinion is
1. It should be mentioned e
On Wed, Mar 19, 2025 at 10:43 AM Mike Schinkel wrote:
>
> Given these benchmark results, would the Go team reconsider such a language
> feature on a basis of performance vs. a comparison of syntax to bring if
> statement performance closer to that of switch statements? The current
> disparity m
20 matches
Mail list logo
