Hi, > is there a special reason why AddOnMonitorHandler *) needs a B_PULSE > message runner to trigger the add-on handling of the pending entries? Why > not just post a B_PULSE into the message queue from within the handler > when a new entry is created? > > Is it really necessary to have a pending entry list? and thus a B_PULSE > message? Why not handle the entries in the same cycle? Ok it makes it a > little bit more multi threaded when scanning the directory the first time > but I see no advantage in this case. It is probably good to handle notifications in the expected thread, and asynchronously to the AddDirectory() call. The mechanism with the pulse messages could be improved. I take it it is supposed to let things settle down a bit. For example a file might quickly appear and disappear and it will be ignored. Also many notifications could arrive and should cause only one action. As you say the pulse message could be send when receiving the first event, that would certainly remove the running of the thread when nothing goes on. Just to give an example of why batching notifications can be good: In the time it takes the linker to produce a new ffmpeg plugin binary, there arrive enough stat changed notifications that the media_server manages to unload the user ffmpeg version, unshadow the system ffmpeg version and reshadow it with the user version about seven to ten times in a row. :-) I put the TODO into the AddOnMonitorHandler before testing this, but I am surprised it would be as important... Best regards, -Stephan