Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Order of the Finalizable process #6

Open
basilex opened this issue Jan 10, 2017 · 3 comments
Open

Order of the Finalizable process #6

basilex opened this issue Jan 10, 2017 · 3 comments

Comments

@basilex
Copy link

basilex commented Jan 10, 2017

Hi, Karl!

The question regarding the order (which in may case is very important) during executing Finalize funcs at the end of an app. So, the code:

package main

import (
	"flag"
	"log"

	"github.com/karlkfi/inject"
)

var (
	ctx        CtxInterface
	indicator  IndicatorInterface
	translator TranslatorInterface

	config = flag.String("config-file", "./etc/banjo-dev.toml", "Banjo configuration file")
)

func main() {
	flag.Parse()

	graph := inject.NewGraph()

	graph.Define(&ctx, inject.NewProvider(NewCtx, config))
	graph.Define(&indicator, inject.NewProvider(NewIndicator, &ctx))
	graph.Define(&translator, inject.NewProvider(NewTranslator, &ctx))
	graph.ResolveAll()

	log.Printf("banjo: indicator: %T, %v", indicator, indicator)
	log.Printf("banjo: translator: %T, %v", translator, translator)

	indicator.Display(translator.T("test1"))
	graph.Finalize()
}

Above snippet of code initializes and executes successfully, but at the end of the application inject calls Finalizable funcs in random order...

First run:

> $ ./bin/banjo-linux-amd64
2017/01/10 11:07:49 banjo: initializing instance ctx...
2017/01/10 11:07:49 banjo: initializing instance indicator...
2017/01/10 11:07:49 banjo: initializing instance translator...
2017/01/10 11:07:49 banjo: indicator: *main.Indicator, &{0xc42000e340}
2017/01/10 11:07:49 banjo: translator: *main.Translator, &{0xc42000e340}
2017/01/10 11:07:49 banjo: instance indicator displaying test1: value
2017/01/10 11:07:49 banjo: finalizing instance indicator...
2017/01/10 11:07:49 banjo: finalizing instance translator...
2017/01/10 11:07:49 banjo: finalizing instance ctx...

Next run:

> $ ./bin/banjo-linux-amd64                                                                                                                    [±master ●●]
2017/01/10 11:07:53 banjo: initializing instance ctx...
2017/01/10 11:07:53 banjo: initializing instance indicator...
2017/01/10 11:07:53 banjo: initializing instance translator...
2017/01/10 11:07:53 banjo: indicator: *main.Indicator, &{0xc42000e340}
2017/01/10 11:07:53 banjo: translator: *main.Translator, &{0xc42000e340}
2017/01/10 11:07:53 banjo: instance indicator displaying test1: value
2017/01/10 11:07:53 banjo: finalizing instance ctx...
2017/01/10 11:07:53 banjo: finalizing instance indicator...
2017/01/10 11:07:53 banjo: finalizing instance translator...

So, do you have some suggestions or recommendations?
Thanks!

@karlkfi
Copy link
Owner

karlkfi commented Jan 10, 2017

Why is it important to you what order they get finalized?

@basilex
Copy link
Author

basilex commented Jan 11, 2017

Easy. Db connection for ex, which should be closed at the end, Indicator (specific device for translated messages) for ex should be closed before translator service and so on... (Imagine "GOOD BYE" for display for ukrainian when translation service already closed...)
Probably graph of the Fanalizable services should be sorted in reverse order?
Thanks!

@karlkfi
Copy link
Owner

karlkfi commented Jan 11, 2017

So your Finalize object functions exec code that depends on the object's dependencies?

I guess that's legitimate.

The map being iterated isn't sorted tho. So it can't just iterate in reverse. It would probably have to keep another array around with the dependency order or capture reverse dependence and walk the tree.

Would you like to make a PR?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants