That looks good to me.
-Paul [the paranoid portability policeman]
On Thu, Apr 24, 2014 at 3:41 AM, Jeff Squyres (jsquyres) wrote:
> On Apr 23, 2014, at 6:38 PM, Paul Hargrove wrote:
>
> > -Paul [Who always does what the late W. Richard Stevens says to.]
>
> You make a good point, sir. How ab
On Apr 23, 2014, at 6:38 PM, Paul Hargrove wrote:
> -Paul [Who always does what the late W. Richard Stevens says to.]
You make a good point, sir. How about this?
diff --git a/src/topology-linux.c b/src/topology-linux.c
index 25fb465..c9dc7e2 100644
--- a/src/topology-linux.c
+++ b/src/topology
On Wed, Apr 23, 2014 at 4:14 PM, Brice Goglin wrote:
> This code is only built on Linux
Yes, of course!
I neglected to look at the name of the file in question.
No guard is needed for even my oldest Linux systems.
-Paul
--
Paul H. Hargrove phhargr...@lbl.gov
Future
This code is only built on Linux so I am not sure we're more portable than OMPI
here. The oldest Linux we've tested bwloc on is likely your machines ;)
Brice
On 24 avril 2014 00:48:46 UTC+02:00, Paul Hargrove wrote:
>Since I suspect hwloc may run on *more* platforms than ompi, I'd
>recommend
>t
Since I suspect hwloc may run on *more* platforms than ompi, I'd recommend
the guards.
The X11 sources actually go as far as the following (Stevens notes that
older systems used '1' before FD_CLOEXEC was specified).
#ifdef F_SETFD
#ifdef FD_CLOEXEC
ret = fcntl (fd, F_SETFD, FD_CLOEXEC);
#e
Currently, POSIX defines exactly one flag accessed via F_GETFD/F_SETFD and
that is FD_CLOEXEC.
However, it does not prohibit a conforming implementation from defining
additional bits.
So, a portable program should assume other bits may be set and try to
preserve them.
Quoting from section 3.14 of
We opened the fd a few lines above with default flags -- is the addition GETFD
necessary?
https://github.com/open-mpi/hwloc/blob/master/src/topology-linux.c#L4595
On Apr 23, 2014, at 6:04 PM, Paul Hargrove wrote:
> In order to preserve any existing flags, shouldn't this be more like:
>
Actually, I just checked around: we have some unprotected FD_CLOEXEC code in
OMPI was that committed 2010-08-24 that has never caused a problem.
So I'm not thinking it should be necessary here, either.
On Apr 23, 2014, at 5:55 PM, Jeff Squyres (jsquyres) wrote:
> Will do.
>
> On Apr 23, 2014
In order to preserve any existing flags, shouldn't this be more like:
int prev;
if ((-1 == (prev = fcntl(root, F_GETFD, 0)) ||
(-1 == fcntl(root, F_SETFD, FD_CLOEXEC | prev)))
On Wed, Apr 23, 2014 at 2:55 PM, Jeff Squyres (jsquyres) wrote:
> Will do.
>
> On Apr 23, 2014, at 5:52 PM
Will do.
On Apr 23, 2014, at 5:52 PM, Samuel Thibault wrote:
> Jeff Squyres (jsquyres), le Wed 23 Apr 2014 21:05:55 +, a écrit :
>> Any objections to this patch? In OMPI, we're seeing this fd leak into child
>> processes.
>>
>> diff --git a/src/topology-linux.c b/src/topology-linux.c
>> i
Jeff Squyres (jsquyres), le Wed 23 Apr 2014 21:05:55 +, a écrit :
> Any objections to this patch? In OMPI, we're seeing this fd leak into child
> processes.
>
> diff --git a/src/topology-linux.c b/src/topology-linux.c
> index e934d4c..8c5fba1 100644
> --- a/src/topology-linux.c
> +++ b/src/t
Looks OK to me.
Brice
Le 23/04/2014 23:05, Jeff Squyres (jsquyres) a écrit :
Any objections to this patch? In OMPI, we're seeing this fd leak into child
processes.
diff --git a/src/topology-linux.c b/src/topology-linux.c
index e934d4c..8c5fba1 100644
--- a/src/topology-linux.c
+++ b/src/top
12 matches
Mail list logo
