So do we add the close on exec or not to to the input pipe ? I'll do a daemon thingie later on and contribute it. So it would start fork and bring up directfb in the sub process then fork directfb clients from itself with a simple messge pipe. The terminals play this game for the same reason so I prob will just look at that code. Its the best way to handle fork And its a easy way to kill directfb if all children exit.
On Jan 2, 2008 12:42 PM, Mike Emmel <[EMAIL PROTECTED]> wrote: > On further thought if you want to do a lot of forking probably the > best solution is to > start your own init like process and fork the main directfb process from that. > Then use this parent for all further fork/exec calls. > Maybe it has its own small fusion world to allow ipc that does > primarily fork/exec calls. > Then we only deal with forking and this simple fusion process manager. > Forking from complex process's is a friggin nightmare. > > > On Jan 2, 2008 11:57 AM, Mike Emmel <[EMAIL PROTECTED]> wrote: > > To be honest I don't know what all needs to happen. > > I suggest we set close on exec on this pipe in the input handlers for now. > > > > Later of we wan't to keep some things open after exec we can consider a api. > > > > Note that most people including me in the end find the rlimit and > > close everything > > but stdin stdout stderr on fork and before the exec anyway. > > > > At the end of the day I'd not even try to do cool stuff with fork its > > not worth it :) > > We have a rich api for allowing to processes to work together. > > > > > > > > On Jan 1, 2008 9:12 AM, Denis Oliver Kropp <[EMAIL PROTECTED]> wrote: > > > Mike Emmel wrote: > > > > I'm running into some fascinating problems related to forking. > > > > > > > > I found this. > > > > > > > > pthread_atfork > > > > > > > > In my particular case I'm having some problems with the X11 demo back > > > > end related to > > > > XShm getting munged after a fork. > > > > > > > > But I'm not clear on whats going on but since DirectFB is multi > > > > threads we may need to consider > > > > if a few more pthreads_atforks are needed. > > > > > > I did not test the FFA_FORK mode with DirectFB at all. I just used it in > > > test application for the Fusion library or in other projects using Fusion > > > for higher level IPC libraries. > > > > > > But it would be interesting if e.g. one application creates and uses a > > > window, > > > then forks and both processes would continue to use the window, surface or > > > receive events for it. It should work... > > > > > > > Googling did not reveal if something needs to be done. I did not find > > > > any use of pthread_atfork in the X11 server either. > > > > > > I'd check for fork() after connecting to the server in an X11 *client*. > > > > > > Is that supported? What happens with sockets? Two processes should not > > > be allowed to receive the same data, should they? I can't imagine there's > > > code in the kernel that "copies" the data to both processes. The server > > > would also have to give the "new" client another client id, like they get > > > a new Fusion ID after forking with FFA_FORK :) > > > > > > -- > > > Best regards, > > > Denis Oliver Kropp > > > > > > .------------------------------------------. > > > | DirectFB - Hardware accelerated graphics | > > > | http://www.directfb.org/ | > > > "------------------------------------------" > > > > > > _______________________________________________ directfb-dev mailing list directfb-dev@directfb.org http://mail.directfb.org/cgi-bin/mailman/listinfo/directfb-dev
