tailieunhanh - Event-Based Programming without Inversion of Control

For example, the read filter for socket descriptors is triggered as long as there is data in the socket buffer greater than the SO LOWAT mark, or when the socket has shutdown and is unable to receive any more data. The filter will return the number of bytes pending in the socket buffer, as well as set an EOF flag for the shutdown case. This providesmore information that the application can use while processing the event. As EOF is explicitly returned when the socket is shutdown, the application no longer needs to make an additional call to read() in order to discover an EOF condition. A non kqueue-aware application using the. | Event-Based Programming without Inversion of Control Philipp Haller Martin Odersky Ecole Polytechnique Federate de Lausanne EPFL 1015 Lausanne Switzerland 1 Introduction Concurrent programming is indispensable. On the one hand distributed and mobile environments naturally involve concurrency. On the other hand there is a general trend towards multi-core processors that are capable of running multiple threads in parallel. With actors there exists a computation model which is especially suited for concurrent and distributed computations 16 1 . Actors are basically concurrent processes which communicate through asynchronous message passing. When combined with pattern matching for messages actor-based process models have been proven to be very effective as the success of Erlang documents 3 25 . Erlang 4 is a dynamically typed functional programming language designed for programming real-time control systems. Examples of such systems are telephone exchanges network simulators and distributed resource controllers. In these systems large numbers of concurrent processes can be active simultaneously. Moreover it is generally difficult to predict the number of processes and their memory requirements as they vary with time. For the implementation of these processes operating system threads and threads of virtual machines such as the Java Virtual Machine 22 are usually too heavyweight. The main reasons are 1 Over-provisioning of stacks leads to quick exhaustion of virtual address space and 2 locking mechanisms often lack suitable contention managers 12 . Therefore Erlang implements concurrent processes by its own runtime system and not by the underlying operating system 5 . Actor abstractions as lightweight as Erlang s processes have been unavailable on popular virtual machines so far. At the same time standard virtual machines are becoming an increasingly important platform for exactly the same domain of applications in which Erlang-because of its process model-has been so .