On Sat, 11 Oct 2014 01:45:48 +0100, Leandro Lucarella <l...@llucax.com.ar>
wrote:
Walter Bright, el 9 de October a las 17:28 me escribiste:
On 10/9/2014 7:25 AM, Dicebot wrote:
>At the same time I don't see what real benefit such runtime options
brings to
>the table. This is why in my PR garbage collector is currently chosen
during
>compilation time.
Choosing at compile time is probably best.
This is not (only) about picking a GC implementation, but also about GC
*options/configuration*. The fact that right now to select between
concurrent or not would mean using a different GC altogether is just an
implementation detail. As I said, if at some point we can merge both,
this wouldn't be necessary. Right now GDGC can disable the concurrent
scanning, among other cool things (like enabling memory stomping,
enabling logging of allocations to a file, enable logging of collections
to a file, controlling the initial pools of memory when the program
starts, etc.).
This is very convenient to turn on/off not exactly at *runtime* but what
I call *initialization time* or program startup. Because sometimes
recompiling the program with different parameters is quite annoying, and
as said before, for stuff that needs to be initialized *before* any
actual D code is executed, sometimes is not easy to be done *inside* D
code in a way that's not horrible and convoluted.
I still don't understand why wouldn't we use environment variables for
what they've been created for, it's foolish :-)
As mentioned this is not a very windows friendly/like solution.
Wouldn't it be more generally useful to have another function like main()
called init() which if present (optional) is called before/during
initialisation. It would be passed the command line arguments. Then a
program can chose to implement it, and can use it to configure the GC in
any manner it likes.
Seems like this could be generally useful in addition to solving this
issue.
R
--
Using Opera's revolutionary email client: http://www.opera.com/mail/
