is there a way to order package init func execute order?

[wheelcomplex]

Hi, groups

is there a way to order package init func execute order?

after read http://localhost:6060/ref/spec#Program_initialization_and_execution , I  can not got a clear information about multi-package initial order when imported in main.

I have search golang-nuts with key word "package init order", no helpful.

I'm sorry if this is a stupid question.

thanks for you read.

[Jan Mercl]

I think the specs (http://golang.org/ref/spec#Program_execution) are
clear and complete on this, for example:

"If a package has imports, the imported packages are initialized
before initializing the package itself. If multiple packages import a
package P, P will be initialized only once.".

Please be more specific, ie. what part you're missing there?

-j

[WheelComplex Yin]

thank you for your relay.

"If a package has imports, the imported packages are initialized
before initializing the package itself. If multiple packages import a

package P, P will be initialized only once.".  

This tell us the order about packages with import relation.

on the other way, I wanna to make sure a special package execute befor all other  packages with no import relations. in the special package, init() will do something system-base init work, such as hardware setup ,etc.

2013/3/28 Jan Mercl <0xj...@gmail.com>

[Jan Mercl]

On Thu, Mar 28, 2013 at 10:24 AM, WheelComplex Yin
<wheelc...@gmail.com> wrote:
> thank you for your relay.
>
> "If a package has imports, the imported packages are initialized
> before initializing the package itself. If multiple packages import a
> package P, P will be initialized only once.".
>
> This tell us the order about packages with import relation.
>
> on the other way, I wanna to make sure a special package execute befor all
> other packages with no import relations. in the special package, init()
> will do something system-base init work, such as hardware setup ,etc.

IIUC:

Solution: Make that package a sole leaf in the dependency tree.

Implementation: Detect current dependency tree leaves and make them
all "import _ my/special/init/pkg".

-j

[Péter Szilágyi]

Hi,

  I don't think it's a wise thing to do. Package init functions were - imho - not conceived to do full program initialization. Their goal is to set up some initial stuff for the local module. I don't think you have control over the init order between packages other than the dependency chain.

  If you need hardware setup, why not just start the main with a function call to do those verifications/configurations? Even if package inits allowed you to do this, it would be much harder to figure out what happens where.

  If you still believe that it must be done in inits, can you provide us with some more details? At the moment I fail to see the need for them.

Cheers,

  Peter

On Thu, Mar 28, 2013 at 10:24 AM, WheelComplex Yin <wheelc...@gmail.com> wrote:

--
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 golang-nuts...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[WheelComplex Yin]

thanks, Jan Mercl and Péter Szilágyi.

sorry, hardware setup is not a good exaple for this.

for my poor english, I write the question in short but make more confusion.

as we know, go 1.0.x runtime has not a office support for daemonize .

https://code.google.com/p/go/issues/detail?id=227

and I have write a pure go package named xdaemon,  like ruby daemonize do:

1. start/stop/status/reload;

2. run in background or foreground;

2. worker processor monitor

3. run worker in no-root user;

4. when run in root, initial tcp socket listener on port < 1024 and send the socket fd to children worker(run as nobody) for security;

5. logging, signal handle etc.

I done this by using os.Exec with specail command args, and it work greate.

for easy to use, I done every thing in package init();

a new application who using xdaemon can focus at the app logic without deal with daemonize/listening/seuid...

xdaemon should be the first package init() to run, to make sure the other package init() only run in worker.

BTW: unix command nohup,  can not done all we need.

ruby daemonize:

http://www.jstorimer.com/2012/04/19/daemon-processes-in-ruby.html
http://stackoverflow.com/questions/3688550/make-a-ruby-program-a-daemon 

2013/3/28 Péter Szilágyi <pet...@gmail.com>

[min...@gmail.com]

https://golang.org/ref/spec

"Package initialization—variable initialization and the invocation of init functions—happens in a single goroutine, sequentially, one package at a time. An init function may launch other goroutines, which can run concurrently with the initialization code. However, initialization always sequences the init functions: it will not invoke the next one until the previous one has returned.

To ensure reproducible initialization behavior, build systems are encouraged to present multiple files belonging to the same package in lexical file name order to a compiler."

[Ian Lance Taylor]

I'm not sure exactly what you are asking.

Perhaps you are asking this. Given a main package that looks like
this

package main

import (
"one"
"two"
)

is there a way to order the initialization of one and two? The answer
is no, there is not.

However, one approach you can use in some cases is to modify package
two to use

import _ "one"

That will ensure that package one is initialized before package two.

If you are asking a different question, I would encourage you to
provide an example.

Ian