没有合适的资源?快使用搜索试试~ 我知道了~
erlang最新api
4星 · 超过85%的资源 需积分: 10 131 下载量 149 浏览量
2012-06-16
13:08:04
上传
评论 2
收藏 1.29MB PDF 举报
温馨提示
试读
448页
erlang最新 api
资源推荐
资源详情
资源评论
STDLIB
Copyright © 1997-2011 Ericsson AB. All Rights Reserved.
STDLIB 1.17.4
May 24 2011
Copyright © 1997-2011 Ericsson AB. All Rights Reserved.
The contents of this file are subject to the Erlang Public License, Version 1.1, (the "License"); you may not use
this file except in compliance with the License. You should have received a copy of the Erlang Public License
along with this software. If not, it can be retrieved online at http://www.erlang.org/. Software distributed under the
License is distributed on an "AS IS" basis, WITHOUT WARRANTY OF ANY KIND, either express or implied. See
the License for the specific language governing rights and limitations under the License. Ericsson AB. All Rights
Reserved..
May 24 2011
Ericsson AB. All Rights Reserved.: STDLIB | 1
1.1 The Erlang I/O-protocol
2 | Ericsson AB. All Rights Reserved.: STDLIB
1 User's Guide
The Erlang standard library STDLIB.
1.1 The Erlang I/O-protocol
The I/O-protocol in Erlang specifies a way for a client to communicate with an io_server and vice versa. The io_server
is a process handling the requests and that performs the requested task on i.e. a device. The client is any Erlang process
wishing to read or write data from/to the device.
The common I/O-protocol has been present in OTP since the beginning, but has been fairly undocumented and has also
somewhat evolved over the years. In an addendum to Robert Virdings rationale the original I/O-protocol is described.
This document describes the current I/O-protocol.
The original I/O-protocol was simple and flexible. Demands for spacial and execution time efficiency has triggered
extensions to the protocol over the years, making the protocol larger and somewhat less easy to implement than the
original. It can certainly be argumented that the current protocol is to complex, but this text describes how it looks
today, not how it should have looked.
The basic ideas from the original protocol still holds. The io_server and client communicate with one single, rather
simplistic protocol and no server state is ever present in the client. Any io_server can be used together with any client
code and client code need not be aware of the actual device the io_server communicates with.
1.1.1 Protocol basics
As described in Roberts paper, servers and clients communicate using io_request/io_reply tuples as follows:
{io_request, From, ReplyAs, Request}
{io_reply, ReplyAs, Reply}
The client sends an io_request to the io_server and the server eventually sends a corresponding reply.
• From is the pid() of the client, the process which the io_server sends the reply to.
• ReplyAs can be any datum and is simply returned in the corresponding io_reply. The io-module in the Erlang
standard library simply uses the pid() of the io_server as the ReplyAs datum, but a more complicated client
could have several outstanding io-requests to the same server and would then use i.e. a reference() or something
else to differentiate among the incoming io_reply's. The ReplyAs element should be considered opaque by
the io_server. Note that the pid() of the server is not explicitly present in the io_reply. The reply can be sent
from any process, not necessarily the actual io_server. The ReplyAs element is the only thing that connects one
io_request with an io_reply.
• Request and Reply are described below.
When an io_server receives an io_request, it acts upon the actual Request part and eventually sends an io_reply with
the corresponding Reply part.
1.1.2 Output requests
To output characters on a device, the following Requests exist:
{put_chars, Encoding, Characters}
{put_chars, Encoding, Module, Function, Args}
1.1 The Erlang I/O-protocol
Ericsson AB. All Rights Reserved.: STDLIB | 3
• Encoding is either 'latin1' or 'unicode', meaning that the characters are (in case of binaries) encoded as either
UTF-8 or iso-latin-1 (pure bytes). A well behaved io_server should also return error if list elements contain
integers > 255 when the Encoding is set to latin1. Note that this does not in any way tell how characters should
be put on the actual device or how the io_server should handle them. Different io_servers may handle the
characters however they want, this simply tells the io_server which format the data is expected to have. In the
Module/Function/argument case, the Encoding tells which format the designated function produces. Note that
byte-oriented data is simplest sent using latin1 Encoding
• Characters are the data to be put on the device. If encoding is latin1, this is an iolist(). If encoding is unicode,
this is an Erlang standard mixed unicode list (one integer in a list per character, characters in binaries
represented as UTF-8).
• Module, Function, Args denotes a function which will be called to produce the data (like io_lib:format), Args
is a list of arguments to the function. The function should produce data in the given Encoding. The io_server
should call the function as apply(Mod, Func, Args) and will put the returned data on the device as if it was sent
in a {put_chars, Encoding, Characters} request. If the function returns anything else than a binary or list or
throws an exception, an error should be sent back to the client.
The server replies to the client with an io_reply where the Reply element is one of:
ok
{error, Error}
• Error describes the error to the client, which may do whatever it wants with it. The Erlang io-module typically
returns it as is.
For backward compatibility the following Requests should also be handled by an io_server (these messages should
not be present after R15B of OTP):
{put_chars, Characters}
{put_chars, Module, Function, Args}
These should behave as {put_chars, latin1, Characters} and {put_chars, latin1, Module, Function, Args} respectively.
1.1.3 Input Requests
To read characters from a device, the following Requests exist:
{get_until, Encoding, Prompt, Module, Function, ExtraArgs}
• Encoding denotes how data is to be sent back to the client and what data is sent to the function denoted by
Module/Function/Arity. If the function supplied returns data as a list, the data is converted to this encoding. If
however the function supplied returns data in some other format, no conversion can be done and it's up to the
client supplied function to return data in a proper way. If Encoding is latin1, lists of integers 0..255 or binaries
containing plain bytes are sent back to the client when possible, if Encoding is unicode, lists with integers in the
whole unicode range or binaries encoded in UTF-8 are sent to the client. The user supplied function will always
see lists of integers, never binaries, but the list may contain numbers > 255 if the Encoding is 'unicode'.
• Prompt is a list of characters (not mixed, no binaries) or an atom() to be output as a prompt for input on the
device. The Prompt is often ignored by the io_server and a Prompt set to '' should always be ignored (and result
in nothing being written to the device).
• Module, Function, ExtraArgs denotes a function and arguments to determine when enough data is written. The
function should take two additional arguments, the last state, and a list of characters. The function should return
one of:
{done, Result, RestChars}
{more, Continuation}
The Result can be any Erlang term, but if it is a list(), the io_server may convert it to a binary() of appropriate
format before returning it to the client, if the server is set in binary mode (see below).
剩余447页未读,继续阅读
czh1986
- 粉丝: 1
- 资源: 3
上传资源 快速赚钱
- 我的内容管理 展开
- 我的资源 快来上传第一个资源
- 我的收益 登录查看自己的收益
- 我的积分 登录查看自己的积分
- 我的C币 登录后查看C币余额
- 我的收藏
- 我的下载
- 下载帮助
安全验证
文档复制为VIP权益,开通VIP直接复制
信息提交成功
- 1
- 2
- 3
- 4
前往页