Plug-in Scanning

Audio Plugins
1

Hi.

The current approach toward plug-in scanning is to try load the host and then mark it as OK.
When encounters a nasty plug-in, the host leaves for the plug-in host’s heaven.

My question is, why won’t the scanning be done in this way:

For each plug-in:

  1. Create a new process that gets the plug-in location and tries to load it.
  2. Once loaded the new process will white-list this plug-in (pipes, white-list file, …) and exist.
  3. If the new process still exists within a predefined timeout, kill it and ban the plug-in.

It will probably slow down scanning but the host will live to see another day.

2

Yes, that’s better of course, but I couldn’t implement that as a C++ class in the library, it’d be up to you to create your own separate app process to do it.

3

Great, Just wanted to know your opinion about that, didn’t see any host what does that.