EPICS Controls Argonne National Laboratory

Experimental Physics and
Industrial Control System

1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  <20052006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024  Index 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  <20052006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
<== Date ==> <== Thread ==>

Subject: RE: autosave V4.1 and caRepeater
From: "Jeff Hill" <[email protected]>
To: "'Lawrence T. Hoff'" <[email protected]>
Cc: <[email protected]>
Date: Fri, 21 Oct 2005 10:22:52 -0600
Larry,

> 	I am curious..... What was the source of the
> complaints that "this was too intrusive"?

I must admit that my memory of the email exchange that motivated this change
is a bit foggy at this point.

I think that intrusive meant that osiSpawnDetachedProcess() is a general
purpose routine, and that if a POSIX code had a pipe open and wanted to
inherit it from a spawned process, they couldn't do that if
osiSpawnDetachedProcess closed all open files.

It appears that this happened.

1) Users discovered that programs like TCL/TK use code in TCL/TK calling
fork/exec and that code does not close the open files. The result was that
CA sockets were duplicated into TCL/TK spawned processes. The best fix
appeared to be to open CA's socket using the FD_CLOEXEC flag given that we
had no control over the fork/exec code in tcl/tk.

2) It appears that it was also decided at that time that the OSI call
osiSpawnDetachedProcess() shouldn't close open files because the FD_CLOSEXEC
flag should suffice for that purpose. I don't recall for certain if I
decided on my own to do this or if someone requested this behavior, but
suspect that the justification at the time was that if tcl/tk, used by
zillions of users, works like that then that's probably a pretty good
default behavior for a general purpose routine like
osiSpawnDetachedProcess().

In any case my current thought is that the following code should be restored
into the POSIX implementation of osiSpawnDetachedProcess() giving it uniform
behavior compared to other OS. 

That's what I currently plan to do, but I am certainly open to suggestions.

    /*
     * close all open files except for STDIO so they will not
     * be inherited by the spawned process
     * since all epics sockets are created with the FD_CLOEXEC
     * option then we no-longer need to blindly close all open
     * files here.
     */
    maxfd = maxPosixFD (); 
    for (fd = 0; fd<=maxfd; fd++) {
        if (fd==STDIN_FILENO) continue;
        if (fd==STDOUT_FILENO) continue;
        if (fd==STDERR_FILENO) continue;
        close (fd);
    } 

/*
 * maxPosixFD ()
 *
 * attempt to determine the maximum file descriptor
 * on all posix systems
 */
static int maxPosixFD ( )
{
	int max;
#       if ! defined (OPEN_MAX)
	static const int bestGuess = 1024;
#       endif

#	if defined (_SC_OPEN_MAX) /* posix */
		max = sysconf (_SC_OPEN_MAX);
		if (max<0) {
#           if defined (OPEN_MAX)
                max = OPEN_MAX;
#           else
			    max = bestGuess;
#           endif
		}
#	elif defined (OPEN_MAX) /* posix */
        max = OPEN_MAX; 
#	else
		max = bestGuess;
#	endif

	return max;
}

Jeff

> -----Original Message-----
> From: Lawrence T. Hoff [mailto:[email protected]]
> Sent: Friday, October 21, 2005 9:14 AM
> To: Jeff Hill
> Subject: Re: autosave V4.1 and caRepeater
> 
> 
> 	Jeff,
> 
> 	I am curious..... What was the source of the
> complaints that "this was too intrusive"?
> 
> 	To first order, I would think that the child
> process should feel free to close anything it wants
> *so long as it has complete control over what it
> executes*. I.e. as long as it only functions as a
> repeater, I don't see how closing other fds could
> be intrusive. If, however, it also executes user code,
> that is a different story....
> 
> 	OTOH, there is a distinct possibility I am
> missing something obvious!
> 
> -- Larry
> 
> P.S.	Here is code I found in an application I
> wrote which ran as a library within an X/Motif
> application, but needed to go off and do some
> processing, returning the data through a defined
> pipe. Everything gets closed except the pipe.
> This was never deemed "too intrusive" despite being
> used on dozens of UNIX architectures and millions
> of users:
> 
> 
>    /* set up IPC */
>    (void)pipe(pipes);
> 
>    /* if we're the parent, return the child ID */
>    pid = fork(); if(pid != (pid_t)0) return pid;
> 
>    /* OK, now let's get ourselves somewhat removed from our parent */
>    {
>      int fd, sig;
>      struct rlimit rlp;
> 
>      /* start by closing all file descriptors (except stderr, and our
> pipe) */
>      (void) getrlimit(RLIMIT_NOFILE, &rlp);
>      for(fd = 3; fd < rlp.rlim_max; fd++) if(fd != pipes[0]) (void)
> close(fd);
> 
>      /* now attach stdin and sdtout to /dev/null */
>      (void) freopen("/dev/null", "r", stdin);
>      (void) freopen("/dev/null", "w", stdout);
> 
>      /* then remove an netscape-installed signal handlers */
>      for(sig=0; sig < 64; sig++)signal(sig, SIG_DFL);
>    }
> 




Navigate by Date:
Prev: RE: autosave V4.1 and caRepeater Mark Rivers
Next: Re: UDP to CA_UDP hangs network? Chris Timossi
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  <20052006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
Navigate by Thread:
Prev: RE: autosave V4.1 and caRepeater Mark Rivers
Next: Re: autosave V4.1 and caRepeater Tim Mooney
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  <20052006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
ANJ, 02 Sep 2010 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·