Erlang OTP 22.0-rc1 is available for testing!

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

Erlang OTP 22.0-rc1 is available for testing!

Henrik Nord X

OTP 22 Release Candidate 1

This is the first of three planned release candidates before the OTP 22 release.

The intention with this release is to get feedback from our users. All feedback i wellcome, even if it is only to say that it works for you,


Erlang/OTP 22 is a new major release with new features, improvements as well as incompatibilities.

Potential Incompatibilities

  • gen_* behaviours, If logging of the last N messages through sys:log/2,3 is active for the server, this log is included in the terminate report.
  • New element, Opts, can now be included in a rel tuple in the reltool release specific configuration format: {rel, Name, Vsn, RelApps, Opts}.
  • All external pids/ports/refs created by erlang:list_to_pid and smilar functions now compare equal to any other pid/port/ref with same number from that node.
  • Old legacy erl_interface library is deprecated as of OTP 22, and will be removed in OTP 23. This does not apply to the ei library.
  • VxWorks is deprecated as of OTP 22 and will be removed in OTP 23.

Known problems

Native code generation does not work for all modules due to new beam instructions not supported by HiPE the native compiler.
Dialyzers automatic compilation to native code does still work.
Building OTP with the configure option enable-native-libs will not work in this release candidate.

Highlights

Erts:

  • Support for Erlang Distribution protocol to split the payload of large signals into several fragments.
  • ETS option write_concurrency now also effects and improves scalability of ordered_set tables.
  • The lenght/1 BIF used to calculate the length of the list in one go without yielding, even if the list was very long, Now yields when called with long lists.
  • A new (still experimental) module socket is introduced. It is implemented as a NIF and the idea is that it shall be as "close as possible" to the OS level socket interface.

Compiler:

  • The compiler has been rewritten to internally use an intermediate representation based on Static Single Assignment (SSA). The new intermediate representation makes more optimizations possible.
    • The binary matching optimizations are now applicable in many more circumstances than before.
    • Type optimizations are now applied across local function calls, and will remove a lot more redundant type tests than before.
  • All compiler options that can be given in the source file can now be given in the option list on the command line for erlc.

Standard libraries:

  • Cover now uses the counters module instead of ets for updating counters. New function cover:local_only/0 allows running Cover in a restricted but faster local-only mode. The increase in speed will vary depending on the type of code being cover-compiled, e.g. the compiler test suite runs more than twice as fast with the new Cover.
  • SSL now uses the new logger API, including log levels and verbose debug logging.

For more details see
http://erlang.org/download/otp_src_22.0-rc1.readme

Pre built versions for Windows can be fetched here:
http://erlang.org/download/otp_win32_22.0-rc1.exe
http://erlang.org/download/otp_win64_22.0-rc1.exe

Online documentation can be browsed here:
http://erlang.org/documentation/doc-11.0-rc1/doc

The Erlang/OTP source can also be found at GitHub on the official Erlang repository,

https://github.com/erlang/otp

OTP-22.0-rc1


Thank you for all your contributions!




_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
Reply | Threaded
Open this post in threaded view
|

Re: Erlang OTP 22.0-rc1 is available for testing!

Andreas Schultz-3
Henrik Nord X <[hidden email]> schrieb am Mi., 27. Feb. 2019 um 13:22 Uhr:

OTP 22 Release Candidate 1

[...] 
  • A new (still experimental) module socket is introduced. It is implemented as a NIF and the idea is that it shall be as "close as possible" to the OS level socket interface.

Is a {active, N} like delivery of data planed or will polling the recv methods be the only way the receive data? What about non-blocking connect and accept?

My preference would be to get an active notification when data is available for receive and another one when when a non-blocking write is possible. Sending and reception should then be left to the caller.
Same goes for non-block accept and connect. Call accept/connect with a async option and get some message when the procedures finishes.

Thanks
Andreas
--
--
Dipl.-Inform. Andreas Schultz

----------------------- enabling your networks ----------------------
Travelping GmbH                     Phone:  +49-391-81 90 99 0
Roentgenstr. 13                     Fax:    +49-391-81 90 99 299
39108 Magdeburg                     Email:  [hidden email]
GERMANY                             Web:    http://www.travelping.com

Company Registration: Amtsgericht Stendal        Reg No.:   HRB 10578
Geschaeftsfuehrer: Holger Winkelmann          VAT ID No.: DE236673780
---------------------------------------------------------------------

_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions