NetBSD-Bugs archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: lib/46111: yplib will hang forever if no server can be found
On Feb 29, 4:35pm, Wolfgang.Stukenbrock%nagler-company.com@localhost (Wolfgang
Stukenbrock) wrote:
-- Subject: Re: lib/46111: yplib will hang forever if no server can be found
| Hi,
|
| I'm not shure if a function is a good idea, because there is already a
| global variable _yplib_nerrs that is set to 5 as default.
| As far as I've figured out _yplib_nerrs is used in some files in
| src/lib/libc/yp and is not documented in any headerfiles and/or the
| manual. It seems to be a global libc-internal variable.
| A disadvantage of a function is the missing ability to query the current
| state.
| So I would prefer a variable, but I can implement a function too, if you
| prefer this.
make it return the current state then, and ignore the setting if the setting
is negative.
| Currently after _yplib_nerrs number of retries the message "YP server
| for ... still trying" is printed, but only if the domain is already
| found in the _ypbindlist. No printing is done for the first contact with
| ypbind - or I've overlooked something.
| This looks like someone has changed the original Sun behaviour in the
| past that is printing this message as far as I remember even for the
| first connection attemp.
| remark: an entry is added to the _ypbindlist after successfull
| contacting ypbind or if a binding file is present and valid.
|
| If there is a binding file present for the domain, and the file locking
| fails, YPERR_YPBIND is returned without contacting ypbind.
| When contacting ypbind, YPERR_YPBIND is returned too if clnttcp_create()
| fails.
| Theese both should be very rare situations, but will already currently
| not wait until a server is available.
|
| In e.g. yp_first and yp_next the variable _yplib_nerrs is used to print
| a message too if the binding has succeeded but the clnt_call() has
| failed the configured number of times. This will be done in an endless
| loop too, if the binding succeded every time.
| Should this behaviour be changed too? If the binding fails, YPERR_DOMAIN
| is returned.
|
| I aggree not to change de default behaviour of the lib, but allow to
| change it unter program control. At least I need currently need the
| possibility to catch the problem with ypbind to faile my request and
| continue to work.
|
|
| My "current" patch will return YPERR_YPBIND only if there is no
| previously setup entry in the _ypbindlist.
| Should I also terminate the processing after <n> retries, if there is an
| entry in _ypbindlist present? I think yes.
| Should in such case the "still trying" message be written to stderr or
| should the lib be silent. I think no printing should be done.
|
| What about the following sollution:
| I reuse _yplib_nerrs for the new functionality.
| _yplib_nerrs > 0 - current behaviour - wait endless and print a
| message every _yplib_nerrs retries. The default value will be 5 as before.
| _yplib_nerrs == 0 - wait endless without printing to stderr
| (this is something that would already happen now when _yplib_nerrs
| gets set to 0, because the print-check check starts with 1 and the first
| printout will happen on the integer-wrap ...)
| _yplib_nerrs < 0 - number of retries (as negative count) with ypbind
| after that YPERR_YPBIND is returned. And the lib will return regardless
| if the domainname has been queried before or not.
| I will add it to the rpcsvc/ypclnt.h headerfile as extern declaration
| and add it the to ypclnt(3) manual.
|
| This implies disabling the printing in the other routines (yp_first etc.
| ) too on none-positive retry numbers.
|
| Is this OK?
I think it is cleaner not to oveload the variable this way and use a new one.
Alterning the behavior of internal variables that are present in most reference
implementations is not a good idea, because if you take the code from NetBSD
to another OS it will not behave as expected. With the new function at least
you get a link error that tells you that you need to do something else.
christos
Home |
Main Index |
Thread Index |
Old Index