diff options
Diffstat (limited to 'lib/ose/doc/src/ose_signals_chapter.xml')
| -rw-r--r-- | lib/ose/doc/src/ose_signals_chapter.xml | 197 |
1 files changed, 197 insertions, 0 deletions
diff --git a/lib/ose/doc/src/ose_signals_chapter.xml b/lib/ose/doc/src/ose_signals_chapter.xml new file mode 100644 index 0000000000..2a6ddb5765 --- /dev/null +++ b/lib/ose/doc/src/ose_signals_chapter.xml @@ -0,0 +1,197 @@ +<?xml version="1.0" encoding="utf-8" ?> +<!DOCTYPE chapter SYSTEM "chapter.dtd"> + +<chapter> + <header> + <copyright> + <year>2013</year><year>2014</year> + <holder>Ericsson AB. All Rights Reserved.</holder> + </copyright> + <legalnotice> + 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. + + </legalnotice> + + <title>Interacting with Enea OSE</title> + <prepared>Lukas Larsson</prepared> + <docno></docno> + <date>2014-01-08</date> + <rev>A</rev> + <file>ose_signals_chapter.xml</file> + </header> + + <marker id="introduction"></marker> + <section> + <title>Introduction</title> + <p>The main way which programs on Enea OSE interact is through the + usage of message passing, much the same way as Erlang processes + communicate. There are two ways in which an Erlang programmer can + interact with the signals sent from other Enea OSE processes; either + through the provided <c>ose</c> module, or by writing a custom linked-in + driver. This User's Guide describes and provides examples for both + approaches. + </p> + </section> + + <marker id="erlang"></marker> + <section> + <title>Signals in Erlang</title> + </section> + + <marker id="driver"></marker> + <section> + <title>Signals in a Linked-in driver</title> + <p> + Writing Linked-in drivers for OSE is very similar to how it is done + for Unix/Windows. It is only the way in which the driver subscribes + and consumed external events that is different. In Unix (and Windows) + file descriptiors (and Event Objects) are used to select on. On OSE + we use signals to deliver the same functionality. There are two large + differences between a signal and an fd. + </p> + <p> + In OSE it is not possible for a signal number to be a unique identifier + for a resource in the same way as an fd is. For example; let's say we + implement a driver that does an asynchronous hunt that uses signal + number 1234 as the hunt_sig. If we want to be able to have multiple + hunt ports running at the same time we have to have someway of routing + the signal to the correct port. This is achieved by supplying a secondary + id that can be retrieved through the meta-data or payload of the signal, + e.g: + <code>ErlDrvEvent event = erl_drv_ose_event_alloc(1234,port,resolver);</code> + The event you get back from + <seealso marker="ose_erl_driver#erl_drv_ose_event_alloc"> + erl_drv_ose_event_alloc</seealso> can then be used by + <seealso marker="erts:erl_driver#driver_select">driver_select</seealso> + to subscribe to signals. The first argument is just the signal number + that we are interested in. The second is the id that we choose to use, + in this case the port id that we got in the + <seealso marker="erts:driver_entry#start">start</seealso> callback is + used. The third argument is a function pointer to a function that can + be used to figure out the id from a given signal. There is a complete + example of what this could look like in + <seealso marker="example">the next section</seealso>. + <note>It is very important to issue the driver_select call before + any of the signals you are interested in are sent. If driver_select + is called after the signal is sent, there is a high probability that it + will be lost.</note> + </p> + <p> + The other difference from unix is that in OSE the payload of the event + (i.e. the signal data) is already received when the ready_output/input + callbacks are called. This means that you access the data of a signal + by calling <seealso marker="ose_erl_driver#erl_drv_ose_get_signal"> + erl_drv_ose_get_signal</seealso>. Additionally multiple signals might be + associated with the event, so you should call + <seealso marker="ose_erl_driver#erl_drv_ose_get_signal"> + erl_drv_ose_get_signal</seealso> until <c>NULL</c> is returned. + </p> + </section> + + <marker id="example"></marker> + <section> + <title>Example Linked-in driver</title> +<code>#include "erl_driver.h" +#include "ose.h" + +struct huntsig { + SIGSELECT signo; + ErlDrvPort port; +}; + +union SIGNAL { + SIGSELECT signo; + struct huntsig; +} + +/* Here we have to get the id from the signal. In this case we use the + port id since we have control over the data structure of the signal. + It is however possible to use anything in here. The only restriction + is that the same id has to be used for all signals of the same number.*/ +ErlDrvOseEventId resolver(union SIGNAL *sig) { + return (ErlDrvOseEventId)sig->huntsig.port; +} + +static int drv_init(void) { return 0; }; + +static ErlDrvData drv_start(ErlDrvPort port, char *command) { + return (ErlDrvData)port; +} + +static ErlDrvSSizeT control(ErlDrvData driver_data, unsigned int cmd, + char *buf, ErlDrvSizeT len, + char **rbuf, ErlDrvSizeT rlen) { + ErlDrvPort port = (ErlDrvPort)driver_data; + + /* Create a new event to select on */ + ErlDrvOseEvent evt = erl_drv_ose_event_alloc(1234,port,resolver); + + /* Make sure to do the select call _BEFORE_ the signal arrives. + The signal might get lost if the hunt call is done before the + select. */ + driver_select(port,evt,ERL_DRV_READ|ERL_DRV_USE,1); + + union SIGNAL *sig = alloc(sizeof(union SIGNAL),1234); + sig->huntsig.port = port; + hunt("testprocess",0,NULL,&sig); + return 0; +} + +static void ready_input(ErlDrvData driver_data, ErlDrvEvent evt) { + /* Get the first signal payload from the event */ + union SIGNAL *sig = erl_drv_ose_get_signal(evt); + ErlDrvPort port = (ErlDrvPort)driver_data; + while (sig != NULL) { + if (sig->signo == 1234) { + /* If it is our signal we send a message with the sender of the signal + to the controlling erlang process */ + ErlDrvTermData reply[] = { ERL_DRV_UINT, (ErlDrvUInt)sender(&sig) }; + erl_drv_send_term(port,reply,sizeof(reply) / sizeof(reply[0])); + } + + /* Cleanup the signal and deselect on the event. + Note that the event itself has to be free'd in the stop_select + callback. */ + free_buf(&sig); + driver_select(port,evt,ERL_DRV_READ|ERL_DRV_USE,0); + + /* There could be more than one signal waiting in this event, so + we have to loop until sig == NULL */ + sig = erl_drv_ose_get_signal(evt); + } +} + +static void stop_select(ErlDrvEvent event, void *reserved) +{ + erl_drv_ose_event_free(event); +} + +/** + * Setup the driver entry for the Erlang runtime + **/ +ErlDrvEntry ose_signal_driver_entry = { + .init = drv_init, + .start = drv_start, + .stop = drv_stop, + .ready_input = ready_input, + .driver_name = DRIVER_NAME, + .control = control, + .extended_marker = ERL_DRV_EXTENDED_MARKER, + .major_version = ERL_DRV_EXTENDED_MAJOR_VERSION, + .minor_version = ERL_DRV_EXTENDED_MINOR_VERSION, + .driver_flags = ERL_DRV_FLAG_USE_PORT_LOCKING, + .stop_select = stop_select +}; +</code> + </section> + +</chapter> |