Should GC hooks be used to help broken software?

[Vsevolod Dyomkin]

Hi,

Did you consider adding a configuration variable that turns this feature on
and off and can be used to set up environments differently for
dev/test/prod?

---
Vsevolod Dyomkin
+38-096-111-41-56
skype, twitter: vseloved

On Sat, Jul 4, 2015 at 4:30 AM, Elias Mårtenson <lokedhs at gmail.com> wrote:

> The following question was raised during my development of an asynchronous
> library <https://github.com/lokedhs/cl-rabbit-async> I'm currently
> building for RabbitMQ.
>
> In summary, the library allows you to create an object of type
> ASYNCH-CONNECTION, from which instances of ASYNC-CHANNEL can be
> retrieved. A connection holds a reference to all channels that it uses, and
> each channel holds a reference to its connection. The connection object has
> a pointer to a native CFFI object that for the underlying connection (my
> library is built on the RabbitMQ C API).
>
> My question is: Should I use trivial-garbage to create a GC hook for the
> connection object so that if the user of the library forgets to close the
> connection, it will get closed eventually once it's GC'ed?
>
> I can see arguments for both behaviours:
>
>    - It's a bad idea, since losing the reference to the connection object
>    means that the program is broken, and silently cleaning up the underlying
>    connection might hide the fact there is a bug (if the GC doesn't run often
>    enough I might have hundreds or even thousands of lingering connections)
>    - On the other hand, it might be a good idea since Lisp developers
>    often use the REPL to experiment, so it's easy to accidentally lose a
>    reference to an object during testing. Thus, using the GC hook will improve
>    the stability of one's development environment.
>
> To me, there is no strictly correct answer to the question, which is why
> I'm asking for suggestions from you guys.
>
> Regards,
> Elias (loke on #lisp)
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/pro/attachments/20150704/5e30769e/attachment.html>