Suggestion - split up mg_startup into 2 pieces?

[GoogleCodeExporter]

Perhaps it is just me (and old-fashioned thinking), but I like to see a
mg_init() and a mg_start() separately, where mg_int() would initialize, and
mg_start() would start the thread. Then in between the two calls is where I
will do my customization, such as mg_set_option(), mg_set_uri_callback(),
and so on. I would like the thread to start listening when I have finished
setting up.

This prevents the small window in which the thread is listening, but I have
not finished setting up all the URI handlers, and a user is connected.

Am I just paranoid? <g>

Original issue reported on code.google.com by PKuo...@gmail.com on 3 Jun 2009 at 2:28

[GoogleCodeExporter]

This is not feasible, since you can later on set any option at runtime. Hence 
there
is no sense of splitting to _init() and _start().
To start listening after the initialization is done, set the "ports" option 
last.

Original comment by valenok on 3 Jun 2009 at 11:11

• Changed state: WontFix

[GoogleCodeExporter]

I had exactly the same thinking when I started to use the new API. Furthermore 
some 
threading issues would just disappear. On the other hand some cool features 
would 
also disappear, like manipulating the uri callbacks at runtime. 
After a lot of thinking (one minute) I tend to prefer also to have a two phase 
start 
up procedure.
Anyway, thank you Sergey for the great EMBEDDED webserver.

Original comment by Mario.Kl...@googlemail.com on 3 Jun 2009 at 11:48

[GoogleCodeExporter]

Could you elaborate more, why would you prefer to split?
Do you mean making mg_set_option() valid only at init time?

Original comment by valenok on 3 Jun 2009 at 11:59

[GoogleCodeExporter]

Just call it "old-fashioned thinking". This term describes it very well. It is 
the 
way I'm dealing with resources in other circumstances. First step, create the 
resource (here a webserver interface), second step, setup the resource, third 
step, 
utilize the resource.
Yes, mg_set_* functions would only be used at init time.
BTW, this discussion already improved my code. I changed the order of my 
mg_set_* 
calls. Now, setting the "ports" option is the last one.

Original comment by Mario.Kl...@googlemail.com on 3 Jun 2009 at 2:34

[GoogleCodeExporter]

Making mg_set_option() init-time-only looks quite restrictive to me, having that
there is no actual need for that. I think of having a possibility to change any 
thing
dynamically as a benefit, so why sacrificing it?

Original comment by valenok on 3 Jun 2009 at 2:49

[GoogleCodeExporter]

If by putting "set ports" last will prevent unwanted connection, that works for 
me.
As a matter of fact, being able to on-the-fly add or remove URI handlers could 
come
in handy at times.

Thanks.

Original comment by PKuo...@gmail.com on 4 Jun 2009 at 8:11