On Friday 25 October 2002 8:59 am, Lars Gullik Bjønnes wrote: > Angus Leeming <[EMAIL PROTECTED]> writes: > | John, > | > | attached is some rough and ready, proof of principle code > | that appears to do the job. > | > | To generate an autosave type > | buffer-auto-save > | in the minibuffer. You should get "Autosaving Buffer" > | printed to the console. If you have the Child Processes > | dialog open, you should also get something flashing up > | there, indicating that the process is being stored by the > | ForkedController as we desire. > | > | I certainly can't generate zombies, but maybe you'll have a > | go too? > > Ok, Good work. > > ...but I am not sure that I agree with the interface. > Especially the ForkedBase(?). > > I was imagining some interface like: > > processController.call(boost::bind(autoSave, &buffer), > Proc::background); > > > which would fork, and run the function object in the newly > created process.
I tried that. The problem is that we'd need template<typename Func1, typename Arg1> processController::call(Func1 & func, Arg1 const & arg1); template<typename Func2, typename Arg1, typename Arg2> processController::call(Func1 & func, Arg1 const & arg1, Arg2 const & arg2); etc. Feel free to prove me wrong here, but my proposed solution is little more than rearranging code that we know works. We are in bug-fixing mode, remember. Deriving all forking processes from forkedProcess seems the most flexible way forward, especially since I can definitely clean things up further. Angus Incidentally, is __EMX__ cygwin? I'm a bit confused by the code in lyx_cb.C that has fork() and that compiles under all architectures and by the code in forkedcall.C that uses fork(), execvp() under unix and spawnvp() under __EMX__. Does fork() work with __EMX__? Angus compiles
