On 2004-03-18 at 08:00:38 [-0500], Ingo Weinhold wrote: > On Wed, 17 Mar 2004, Michael Phipps wrote: > > > Jérôme - > > > > That is a very good catch of a race condition (it shouldn't happen - the > > lowest time it can take for a SS to get invoked is 30 seconds, but > > still...) I fixed it, as you suggested, but the input_server still crashes. > > > > Any other ideas? > > The code you gave looks OK in principle. Did you try to track the bug down > systematically? That is starting with uncommenting the creation of the Yes. > message runner and the addition of the message filter and see if it still > crash, then uncommenting only one of them and the complete contents of the > filter hook function, then only a part and so on... Tedious, but should help > to track the problem down. Maybe a telnet session can least release you from > restarting the whole system after an input server crash. It crashes on the adding of the filter. Even if the filter's function does nothing, it still crashes. I built a quick and dirty install script for testing - it installs the ISF and restarts input_server. It then waits 30 seconds, deletes the ISF and restarts the input_server. So if it works, I can just hit control-c to break. If it doesn't, after 30 seconds, I will have control back. > That being said, I want to say, that a message filter is a bit of overkill > anyway. How about making your input server filter a BHandler, adding it to > the be_app and directing the message runner messages to it directly? An ISF is a class - unless I wanted to try multiple inheritance, I can't do that. If that is what you are suggesting, well, cool. :-) > And take care not to forget to uninstall whatever you use in the destructor, > since when your add-on is unloaded, the message filter hook function > respectively your class' code will be gone, which will cause the server to > crash, when it tries to enter that code. That is true. I didn't do that, but I will.