Events: Difference between revisions

 

The event interface:

procedure Signal;

procedure Reset;

private

Fired : Boolean := False;

The event implementation:

procedure Signal is

begin

null;

end Wait;

With the event defined above:

 

procedure Test_Events is

Put_Line ("Signal X");

X.Signal;

Sample output:

<pre>

 

=={{header|AutoHotkey}}==

Return

 

F2:: ; external event: fire on F2 key press

TrayTip, external, f2 key pressed

 

=={{header|BBC BASIC}}==

===API===

This uses a Windows event object:

WAIT_TIMEOUT = 258

DEF PROCelapsed

SYS "SetEvent", hEvent%

===Native===

This uses a simple variable as a semaphore:

Event% = FALSE

DEF PROCelapsed

Event% = TRUE

 

=={{header|C}}==

Using pipe to communicate to <code>fork</code>ed child. Since child will be blocking trying to read the other end of the pipe, this can be used for synchronization.

#include <unistd.h>

 

}

return 0;

 

=={{header|C sharp|C#}}==

using System.Timers;

 

((Timer)sender).Stop();

}

Sample output:

<pre>10-11-2010 18:35:11

10-11-2010 18:35:12</pre>

 

=={{header|Delphi}}==

 

{$APPTYPE CONSOLE}

end;

Readln;

Sample output:

<pre>

 

=={{header|E}}==

def [var fired, var firer] := Ref.promise()

return event

The event object has this behavior: the return value of <code>.wait()</code> will be resolved after the time of the earliest <code>.signal()</code> for which there is no intervening <code>.reset()</code>.

 

{

})

println("[1] Waiting 1 second...")

 

=={{header|Erlang}}==

Events can be implemented by using the selective receive expression and erlang's built in message passing. Here task waits for the message 'go' before it will continue.

-module(events).

-compile(export_all).

P ! go,

timer:sleep(100).

'''Output:'''

66> events:main().

0: 0:57 => Program start

0: 0:58 => Task resumed

ok

 

=={{header|F_Sharp|F#}}==

{{trans|C#}}

open System.Timers

 

timer.Start()

ignore <| Console.ReadLine()

 

=={{header|Go}}==

A Go channel can represent an manual-reset event, as described by the task. The two states of signaled and reset correspond to the presence or absence of a value on the channel. The program signals by sending a value on the channel. The event is reset when the waiting task explicitly executes the channel receive operation, <-event.

 

import (

event <- 0

time.Sleep(100 * time.Millisecond)

{{out}}

<pre>

 

=={{header|Haskell}}==

import Control.Concurrent.SampleVar

 

signalEvent (Event sv) = writeSampleVar sv ()

resetEvent (Event sv) = emptySampleVar sv

forkIO (waitTask e)

putStrLn "[1] Waiting 1 second..."

waitTask e = do putStrLn "[2] Waiting for event..."

waitEvent e

Note: Because there is no serialization of the text output, there is a chance that it will appear interleaved.

 

The following only works in Unicon. The example illustrates the multiple tasks can

receive the same event:

 

procedure main()

signal(event.cond,0)

every wait(t1|t2)

 

Sample run:

Task one received event.

->

</pre>

 

=={{header|LFE}}==

 

(defun log (msg)

 

(defun task ()

(log "Task resumed"))

 

(log "Program start")

(let ((pid (spawn (lambda () (task)))))

(! pid 'go)

(timer:sleep 100))))

 

 

 

Mathematica supports events from timers (via Pause[]), task schedule descriptors. This will print a message after 4 seconds, then terminate the program.

 

=={{header|Nim}}==

{{trans|C}}

 

var p: array[2, cint]

discard p[1].write(addr p[0], 1)

var x: cint = 0

else:

discard close p[1]

discard p[0].read(addr p[1], 1)

 

 

=={{header|Oforth}}==

An event is often implemented with a control channel. A task is waiting for an object on the channel. When the event occurs, another task sends an object on this channel.

 

| ch |

Channel new ->ch

#[ ch receive "Ok, event is signaled !" println ] &

System sleep(1000)

 

An emitter is a general implementation for handling events : an emitter waits for events emitted and launches listeners that are waiting for those events.

| e i |

Emitter new(null) ->e

 

=={{header|Oz}}==

{{trans|Haskell}}

Events can be implemented as mutable references to dataflow variables:

fun {NewEvent}

{NewCell _}

{Delay 1000}

{System.showInfo "[1] Signaling event."}

However, this code is quite unidiomatic. If we need to wait for an event just once (like in this example), we can simply use a dataflow variable, i.e. an event that cannot be reset:

E

in

{Delay 1000}

{System.showInfo "[1] Signaling event."}

If we want to synchronize two threads repeatedly and exchange data, it is natural to use ports and streams. Streams are just lists with an unbound tail. A port is basically a pointer to the tail of a list, i.e. it keeps track of where the next event can be written to:

MyPort

in

{System.showInfo "[1] Signaling event."}

{Port.send MyPort unit}

It is important to limit the scope of a stream as much as possible to ensure that the already read part of the stream is garbage-collected.

 

This is an example of using the [http://search.cpan.org/perldoc?AnyEvent AnyEvent] module.

The result is this: it prints "Hello world!" after one second, then after another second prints "Hi!" four times every quarter of a second and then immediately prints "Bye!" and quits:

 

# a new condition with a callback:

 

# wait for the $quit condition to be ready:

This is the same using AnyEvent [http://search.cpan.org/perldoc?AE simplified API]:

 

my $quit = AE::cv sub { warn "Bye!\n" };

};

 

 

{{out}}

 

=={{header|PicoLisp}}==

This will print a message after one second, then terminate the program after

another four seconds:

(prinl "Exit in 4 seconds")

 

=={{header|PureBasic}}==

ButtonGadget (1, 10, 10, 35, 20, "Quit")

 

EndIf

 

=={{header|Racket}}==

the task (since it's a useless value):

 

#lang racket

 

 

(void (sync task)) ; wait for the task to be done before exiting

 

=={{header|REXX}}==

Although REXX can be event driven, most events would probably have to be actively checked to see if the event occurs.

 

end /*forever*/

 

<pre>

an event occurred at 16:13:29, the event is: 9

an event occurred at 16:13:51, the event is: 1

an event occurred at 16:13:53, the event is: 3

</pre>

 

=={{header|Tcl}}==

Tcl has been event-driven since 7.5, but only supported channel and timer events (plus variable traces, which can be used to create event-like entitites). With the addition of coroutines, it becomes much simpler to create general events:

{{works with|Tcl|8.6}}

proc pause ms {

after $ms [info coroutine];yield

X signal

}

Output:

<pre>waiting for event

received event</pre>

Of course, the classic way of writing this is much shorter, but intermingles the tasks:

puts "waiting for event"

vwait X

 

=={{header|zkl}}==

zkl provides an Atomics library for things like this. Events are async, waiting for an event doesn't poll.

// create thread waiting for event

fcn(event){event.wait(); println(vm," ping!")}.launch(event);

Atomic.sleep(1);

event.set();

{{out}}

<pre>