[go-nuts] unit testing a finalizer (or: cleaning up main loops)

Hey guys,

Long story short:

- How do you clean up main loops in libraries?

- How do you test code that uses SetFinalizer()?

Background:

Sometimes I use the "main loop" paradigm to make an object safe for
concurrent use. Basically, you have a New() routine that creates a new
object and starts a main loop in a goroutine. This main loop listens for
operations on a channel and you expose that channel directly (or indirectly
using accessor methods) to the user.

Great.

How do you clean this up when the object is no longer used? A .Close()
method works. I'd rather avoid that if I can, because .Close is extra work
(at the risk of forgetting it) for the user.

Ideally I'd like to stop the main loop once the garbage collector reclaims
the object.

Now I have something which *I think* works: how do I test it? It's a tricky
system and the tests I wrote succeed on my machine, but on Travis-CI not
even the simplest use of .SetFinalizer ever does anything.

Do I just leave it in and assume that because it works here, it works
everywhere?

Or does using a main loop like this require users to .Close()? Then I'd
rather use a lock.

Here is Travis not running any finalizers (not even a very simple one on an
integer):

https://travis-ci.org/hraban/testtravis/builds/22570080

This test passes every single time on my box. I tried crazy stuff to get the
GC juices flowing, to no avail.

It's a stripped down version of this project:

https://github.com/hraban/lrucache

Greetings,

Hraban

--
You received this message because you are subscribed to a topic in the
Google Groups "golang-nuts" group.
To unsubscribe from this topic, visit
https://groups.google.com/d/topic/golang-nuts/64SCXa0Ls0o/unsubscribe.
To unsubscribe from this group and all its topics, send an email to
[email protected].
For more options, visit https://groups.google.com/d/optout.

On Wed, Apr 9, 2014 at 3:43 AM, Hraban Luyat wrote:
Hey guys,

Long story short:

- How do you clean up main loops in libraries?

- How do you test code that uses SetFinalizer()?

Background:

Sometimes I use the "main loop" paradigm to make an object safe for
concurrent use. Basically, you have a New() routine that creates a new
object and starts a main loop in a goroutine. This main loop listens for
operations on a channel and you expose that channel directly (or indirectly
using accessor methods) to the user.

Great.

How do you clean this up when the object is no longer used? A .Close()
method works. I'd rather avoid that if I can, because .Close is extra work
(at the risk of forgetting it) for the user.

Ideally I'd like to stop the main loop once the garbage collector reclaims
the object.

Now I have something which *I think* works: how do I test it? It's a tricky
system and the tests I wrote succeed on my machine, but on Travis-CI not
even the simplest use of .SetFinalizer ever does anything.

Do I just leave it in and assume that because it works here, it works
everywhere?

Or does using a main loop like this require users to .Close()? Then I'd
rather use a lock.

Here is Travis not running any finalizers (not even a very simple one on an
integer):

https://travis-ci.org/hraban/testtravis/builds/22570080

This test passes every single time on my box. I tried crazy stuff to get the
GC juices flowing, to no avail.

It's a stripped down version of this project:

https://github.com/hraban/lrucache

Greetings,

Hraban

--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to [email protected].
For more options, visit https://groups.google.com/d/optout.

Your "main loop" goroutine references the object, so it will never be
garbage collected (finalizer will never run).
You need to at least explicitly stop the main loop goroutine. And if
you do it eplicitly with Close, it's simpler to cleanup everything
else in that Close call.

On Wed, Apr 9, 2014 at 4:05 AM, Hraban Luyat wrote:
Hi,

Thanks for the replies. I'm sad you need .Close for something that
uses goroutines this way, that makes using locks a better alternative
from the user of your library's perspective.

Just for the record: the main loop is not referencing the object
(Cache struct), it's referencing a member (the operation channel). The
struct goes out of scope at the end of leakingGoroutinesHelper().

Greetings,

Hraban

2014-04-09 8:53 GMT+02:00 Dmitry Vyukov <[email protected]>:

How the goroutine can act on the cache, if it's not referencing it?..

On Wed, Apr 9, 2014 at 4:47 AM, Hraban Luyat wrote:
It's getting a reference to the cache wrapped in every operation (see
func (c *Cache) Msg()). This reference is kept by the user of the
library (leakingGoroutinesHelper() in this case).

Greetings,

Hraban

2014-04-09 13:40 GMT+02:00 Dmitry Vyukov <[email protected]>:

2014-04-09 13:51 GMT+02:00 Dmitry Vyukov <[email protected]>:
I've failed to find the sources.