<HTML><HEAD> <META http-equiv=Content-Type content='text/html; charset=windows-1252'> <title>Samsung Enterprise Portal mySingle</title> <style> P, td, li {font-family:Arial, arial; font-size:9pt; margin-top:5px;margin-bottom:5px;} body{font-family:Arial, arial; font-size:9pt;}</style> </HEAD><BODY> Hi,   Keeping connection across fork is too much hassle and not worth the effort. No doubt about it.  it violates the rule of thumb 'make it simple but not too simple'.. let the forked child process able to re-run dbus_g_bus_get.   it is sufficient to have a simple API like 'dbus_g_connection_half_close' (half closed connection from TCP definition). It should be the api works and used just like fclose(fd) on unix pipe or domain socket which must be closed when forked.   of course.. It will be broken in Windows Socket implemetation.     Sean Samsung   ------- Original Message ------- Sender : Thiago Macieira<thiago@kde.org> Date : 2007-04-06 01:53 Title : Re: dbus fork problem Havoc Pennington wrote: >Hi, > >Even in theory I'm not sure how a connection kept across fork() would >work... the behavior would be tough to define. > >If you can spec out what you need then we can discuss the API. I propose we don't do anything about it. If the application must do fork()  and both processes have working connections, at least one of the  connections should be a private one. And the connection used in the child  process should be opened only after forking. The reason for that is that any other solution would probably break  states: suddenly a plugin or library finds itself in a new connection  (with a new unique name and without its well-known names). To properly handle this case, libdbus would need an entry point to be  told "we have forked", so that it can close the connections and reopen  them (might fail!!), then call back to the binding code with such  information. And the bindings must propagate the information down to user  code. In all, not worth it IMHO. --    Thiago Macieira  -  thiago (AT) macieira.info - thiago (AT) kde.org     PGP/GPG: 0x6EF45358; fingerprint:     E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358 </BODY></HTML>