Brad Nicholes wrote: >>>> On 12/11/2009 at 6:21 AM, in message <[email protected]>, >>>> Daniel >>>> > Pocock <[email protected]> wrote: > > >>> it replaces apr_proc_detach with an inline implementation of it on plain >>> POSIX and that should be most likely as portable (at least for the platforms >>> we care of) and doesn't intentionally include any error checking to make it >>> >>> >> How about Cygwin and mingw? I'm not sure if the use of pipe(), fork(), >> etc is possible there >> >> I think we need to take a broader decision about the way we support the >> Windows platform anyway, we may not need to support detach on that >> platform. With Cygwin or with mingw, we should be able to include >> native code for running as a service. >> >> So my proposal would be that we extend Carlo's concept so that there are >> two variations of it, using #ifdef : >> >> - a UNIX variation of gmond that has detach functionality implemented >> with fork, pipe, etc >> >> - a Windows variation of gmond that has built in support for running as >> a service >> >> The cygrunsrv source code here provides us with an example of how to go >> about it: >> >> http://sourceware.org/cgi-bin/cvsweb.cgi/cygrunsrv/?cvsroot=cygwin-apps#dirlis >> >> t >> >> What do people think about having this type of native code in gmond >> rather than just using apr? Or should we try to patch apr to provide >> the functionality? >> >> > > I have to admit that I haven't dug into this issue to understand exactly why > we are having problems with APR. APR is designed to solve these problems in > a cross platform way and we are proposing that we abandon the cross platform > solution in favor of a platform specific solution. I know that httpd doesn't > have these issues and they detach and run just fine across a wide variety of > platforms including windows, BSD, solaris, etc. Why are we having these > problems when httpd doesn't? Is the real solution as simple as going to the > APR mailing list and asking why this issue exists in APR and if there is a > workaround? I haven't really seen this issue show up on the APR mailing list > so far or did I miss it? > > One of the problems that we already have with gmond is that there is already > too much platform specific code in it which is why we have to rely on cygwin > in order to run on windows. It is also the reason why gmetad doesn't really > run on windows because it wasn't built on top of a cross platform solution. > My gut feel is that we should be moving ganglia more towards APR rather than > away from it. > > I agree - we should use APR for everything that it does in a useful way. Network routines, memory management, time functions, etc.
I don't believe APR provides a solution for making a binary that can be started and stopped using the service manager in Windows. Therefore, I don't see what that should not be an extra bit of code that we support in Ganglia. It is something that is unique to the Windows environment, but useful nonetheless. However, the detach issue, and it's impact on pollsets, is another matter, as it differs between Linux and BSD - maybe that is something we should run through the APR mailing list before we abandon apr_proc_detach - however, if the only solution is a future version of APR, then we might still need to have some workaround within gmond. ------------------------------------------------------------------------------ Return on Information: Google Enterprise Search pays you back Get the facts. http://p.sf.net/sfu/google-dev2dev _______________________________________________ Ganglia-developers mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/ganglia-developers
