A very basic list of what happens in version 4.1:
The sensorApp process receives the modified configuration.
SensorApp does some initial evaluation on the config to make sure it is valid.
SensorApp stops monitoring traffic and builds new state tables for any modifications made to regular expressions (state tables are also rebuilt if signatures using regexes are enabled or disabled).
Once the new state tables are built the sensorApp responds back to the configuration tool (in the CLI you notice the command is complete).
Now sensorApp restarts itself with the new validated configuraiton.
NOTE: This is just sensorApp restarting and not any of the other processes. Processes trying to communicate with sensorApp (like IDM asking for the current sensorApp configuration) will timeout or receive an error while sensorApp is busy generating the new state tables or restarting with the new configuration.
If no regex tables have to be built then the reconfiguration goes fairly quickly (less than a minute). But if there are multiple regex modifications or if there are multiple signatures enabled or disabled that use regex, then it takes quite a while longer. Depending on the changes made the modification could take a minute to 20 minutes (on the low end platforms).
NOTE: In version 4.0 we use to keep traffic going while the sensor rebuilt the state tables. This caused the rebuild to take much longer than it does now in 4.1.
NOTE: In version 3.1 the new config files would be written and packetd would restart itself to read the new configurationss. Packetd would then also build these same state tables. The difference in 4.1 and 3.1 is that 4.1 doesn't respond back that the config was accepted until after the state tables were built, but in 3.1 packetd would accept the config and restart before building the state tables.
We are working on this and trying to speed up this reconfiguration process.
This same process also takes place when a signature update is done on version 4.1 sensors.
