[toast0]

This would be terrible in production -- often there's an order you need to load the beam files, and I wouldn't want to add that to the compile step, it's very simple to load in the proper order. You could pretty easily use code:soft_purge/1 prior to loading to avoid killing lingering processes though, and then it would probably be reasonable for development.

[simoncion]

> This would be terrible in production...

Yeah it could be. Frankly, I'd likely reach for Erlang Releases before I reached for this when updating software in production.

However, for a large variety of dev work, this automatic module reloading thingie works pretty well. :)

> You could pretty easily use code:soft_purge/1 prior to loading to avoid killing lingering processes though...

Mmm. Okay. So, I'm not 100% on how this works, so please bear with me and my inaccurate terminology. :(

In any given Erlang system, there can be two versions of a module running, the "current" one, and the "old" one, right?

So, if you call code:soft_purge/1 when there is no "old" code loaded, it should return true, yes? (In addition to returning true when there's no process running the "old" code.) [0]

So, would this be a way to write an auto-loader that doesn't purge in-use code?

* code:soft_purge(?MODULE)

* if false, wait a while then retry

* if true, code:load_file(?MODULE)

I guess maybe you'd want to build up a list of all the modules that have been modified, and wait until code:soft_purge/1 returns true for all of them before loading the modules. (maybe.)

You also -obviously- want an override that allows for the purging of in-use code.

[0] Testing indicates that it does, but it's often good to double-check. :)

[toast0]

Yes, you've got the concepts and implementation correct.

The exact strategy for reloading (wait for all at once, load whatever is ready, how long to wait, etc), left as an exercise for the reader. For dev, I use a function in the shell that loads everything that changed (no soft purge), for prod, i have a function that goes in order and checks soft purge, then loads (if the 2nd module doesn't soft purge, it will have already loaded the first module, but it will stop before trying the 3rd).

With most things in gen_server's, there's not a lot of opportunity for lingering code, but sometimes it happens.