[yetihehe]

When your server has several gigs of state. It's VERY useful on a dev server. Instead of waiting several minutes for reload, I just load in new code manually (typically I change only 1-2 files per reload). If something breaks - hey, it's only dev server. Erlangs other feature - almost everything works alone - helps with this. If something breaks, it breaks only in one place, so most of the time I only need to make small changes and reload once more. Rest of the system does what it needs without any downgrades.

[simoncion]

> Instead of waiting several minutes for reload, I just load in new code manually (typically I change only 1-2 files per reload). If something breaks - hey, it's only dev server.

Someone wrote a module for elixir that uses inotify (and similar) to -I think- watch .beam files for modification and perform the required hot-reloads automatically.

I would be reluctant to run this in production, and I can see situations (even in development) where this could trigger unwanted code purging and would be disastrous, but it's a pretty neat thing to have and -it seems- a must for Web Dev people.

[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.