XROOTD-L Archives

Support use of xrootd by HEP experiments

XROOTD-L@LISTSERV.SLAC.STANFORD.EDU

Options: Use Forum View

Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Subject:
From:
Date:
18 Aug 2004 22:36:52 +0200Wed, 18 Aug 2004 22:36:52 +0200
Content-Type:
text/plain
Parts/Attachments:
text/plain (52 lines)

Hi Gregory,

Thanks for the observations. Some of the things you point out are historical
in nature, some are there for modularity, and others for portability or
compatbility. Here are some examples:

>    allow host xyz.standford.edu
>If that is correct, the comment at the start of xallow should point
>that out. The syntax description does indicate that the host/netgroup
>argument is optional, but doesn't state the default.  Another solution
>is to make it mandatory.
Quite correct, the documentation is lacking here. As for making things
mandatory, many times our hands are tied. There are a lot of config files
(not necessarily ours) that, for one reason or another, use the implied
default. Our commitment has been to make any changes upwardly compatible to
minimize the admin frustration level.

>If I read the code correctly, the Meter code just execs the
>monitor process using custom code that looks a lot like a
>reimplementation of popen().
Good observation. We've found that popen() is not thread-safe on some
platforms. We've side-stepped the issue by just doing a thread-safe
implementation.

> General observations:
> 1. The configuration file-reading code is effectively replicated 4 times.
In some sense this is historical as each subcomponent was implemented
independently of each other. Over time we've converged on a common way of
doing things. However, other pressing developments pretty much caused us to
stop at what you see. It may not be the prettiest code but at least it's
debugged.

> 2. There are several unnecessary casts in the code. Casting variables
> of type "char *" to (const char *) when passing them as arguments to
> functions expecting a (const char *) is redundant.
Well, yes and no. It really depends on the compiler. In trying to support a
rather lartge set of compilers we've found that some care about constness
and some don't. I suppose we could mandate the compiler but compilers, like
editors, fall into religuos territory and we've decided not to enter the
fray. So far, the only common thing is that they don't seem to care about
redundant casts when it does occur so that satisfies the compilers that
simply do a syntactic check for type compatability.

>I hope these are helpful.
Absolutely, thank you for the suggestions and corrections. As many as we can
encorporate will go in.

Andy



ATOM RSS1 RSS2