| Age | Commit message (Collapse) | Author |
|---|
|
As of this version, the global name server no longer supports nodes running
Erlang/OTP R11B.
|
|
A race condition in os:cmd/1 could cause the caller to get stuck in
os:cmd/1 forever.
|
|
|
|
|
|
* rani/inet_gethostbyname_fixes:
inet_res_SUITE: testcase fixes for legacy DNS resolver (Solaris 8)
inet_res: /etc/resolv.conf: use domain as default search list
inet: delayed/avoided read of /etc/resolv.conf and /etc/hosts
inet_gethost_native: workaround for empty result hostname on MacOS X
inet_res_SUITE: testcase fix for empty domain name
inet:gethostbyname improved to parse IP strings and look up own hostname
OTP-8426 The resolver routines failed to look up the own node name as
hostname, if the OS native resolver was erroneously configured,
bug reported by Yogish Baliga, now fixed.
The resolver routines now tries to parse the hostname as an IP
string as most OS resolvers do, unless the native resolver is
used.
The DNS resolver inet_res and file resolver inet_hosts now do not
read OS configuration files until they are needed. Since the
native resolver is default, in most cases they are never needed.
The DNS resolver's automatic updating of OS configuration file
data (/etc/resolv.conf) now uses the 'domain' keyword as default
search domain if there is no 'search' keyword.
|
|
|
|
When the search list option in /etc/resolv.conf was empty, the
domain option was not used as default search domain.
That has been fixed in this patch.
|
|
|
|
Now inet:gethostbyname tries to parse the hostname as an IP string
first if the 'native' lookup method is not used. One can also
make the IP string parsing explicit using the new 'string'
lookup method, or avoid it using the new pseudo lookup
method 'nostring'.
In R13B04 a bug was introduced when the gethostbyname code
was rewritten, so if the native resolver was used and
misconfigured to not be able to look up the own hostname,
inet:gethostbyname also failed. This is now fixed.
|
|
* sc/sctp-connect-nowait:
Implement a non-blocking SCTP connect
OTP-8414 There are new gen_sctp:connect_init/* functions that initiate an
SCTP connection without blocking for the result. The result is
delivered asynchronously as an sctp_assoc_change event. (Thanks
to Simon Cornish.)
|
|
This patch adds a new set of functions - gen_sctp:connect_init/* that initiate
an SCTP connection without blocking for the result. The result is delivered
asynchronously as an sctp_assoc_change event.
The new functions have the same API as documented for gen_sctp:connect/* with
the following exceptions:
* Timeout is only used to supervise resolving Addr (the peer address)
* The possible return values are ok | {error, posix()}
The caller application is responsible for receiving the #sctp_assoc_change{}
event and correctly determining the connect it originated from (for example,
by examining the remote host and/or port). The application should have at
least {active, once} or use gen_sctp:recv to retrieve the connect result.
The implementation of gen_sctp:connect suffers from a number of
shortcomings which the user may avoid by using gen_sctp:connect_init and
adding code to receive the connect result.
First, irrespective of the Timeout value given to gen_sctp:connect, the OS
attempts and retries the SCTP INIT according to various kernel parameters. If
the Timeout value is shorter than the entire attempt then the application will
still receive an sctp_assoc_change event after the {error, timeout} is
returned from the initial call. This could be somewhat confusing (either to
the application or the designer!) especially if the status is
comm_up. Subsequent calls to connect before the OS has finished this process
return {error, ealready} which may also be counter-intuitive.
Second, there is a race-condition (documented in comments in inet_sctp.erl)
that can cause the wrong sctp_assoc_change record to be returned to an
application calling gen_sctp:connect. The race seriously affects connection
attempts when using one-to-many sockets.
|
|
|
|
Add first batch of tests for code:clash/0.
Signed-off-by: Tuncer Ayaz <[email protected]>
|
|
There was a small typo in the doc function clause of ext_mod_dep.
Signed-off-by: Tuncer Ayaz <[email protected]>
|
|
* bg/cleanup-tests:
file_SUITE: eliminate a warning for an unused variable
kernel tests: modernize guard tests
unicode_SUITE: replace deprecated concat_binary/1 with list_to_binary/1
stdlib tests: modernize guard tests
Test suites: fix creation of Emakefiles
|
|
|
|
|
|
The Emakefiles in some test suite directories are only appended
to, never created from scratch, which can cause problems
especially when swithching branches in a git repository.
|
|
For example, if an archive (app-vsn.ez) just contains an
app-vsn/ebin/mod.beam file, the file info for the app-vsn and
app-vsn/ebin directories are faked using the file info from the
archive file as origin. The virtual direcories can also be
listed. For short, the top directories are virtual if they does
not exist.
|
|
|
|
An on_load function is supposed to return 'true' to indicate
that the module should be loaded, and 'false' if it should be
unloaded. But returning any other term, as well as causing an
exception, will also unload the module.
Since we don't like boolean values mixed with other values,
change the expected return value as follows:
* If 'ok' is returned, the module will remain loaded and become
callable.
* If any other value is returned (or an exception is generated),
the module will be unloaded. Also, if the returned value is
not an atom, send a warning message to the error_logger
(using error_logger:warning_msg/2).
The new interpretation of the return value means that an on_load
function can now directly return the return value from
erlang:load_nif/2.
|
|
|
