| Age | Commit message (Collapse) | Author |
|---|
|
* 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.
|
|
code:clash/0 did not take into account .ez files
when listing contents of code path entries.
Using erl_prim_loader:list_dir/1 instead of
file:list_dir/1 fixes the problem.
Signed-off-by: Tuncer Ayaz <[email protected]>
|
|
|
|
Loading native code is a multi-step operation that needs to be
atomic, but the HiPE loader failed to ensure that.
This caused corruption of runtime system structure in some cases.
Fix by blocking multi_scheduling around main loader entry points.
Signed-off-by: Mikael Pettersson <[email protected]>
|
|
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.
|
|
bug was introduced in R13B03.
|
|
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.
|
|
|
