Home

Awesome

(c) Sierra Wireless, 2007-2013

WARNING

The scheduler is now distributed as part of Mihini. This version isn't maintained anymore.

About

Sched is a Lua collaborative scheduler: it allows several Lua tasks to run in parallel, and to communicate together when they need to interact.

It offers a convinient way to write programs which address multiple I/O driven issues simultaneously, with much less hassle than with preemptive multithreading frameworks; it also doesn't require developers to adopt unusual programming styles, as expected by Erlang, map-reduce variants, or callback-driven frameworks such as node.js. Among other appropriate usages, it allows to easily write and deploy the applications typically powering machine-to-machine infrastructures.

This repository is a preliminary and separate release of Lua sched, normally part of Sierra Wireless' M2M development framework.

A developer preview of Sierra Wireless' Lua SDK is available on the Lua Workshop '11 website [PDF].

Content

Third party projects

This project includes the following 3rd party projects, all under MIT or other MIT-compatible public licenses:

Sierra Wireless Modules

The following modules have been developped and are released by Sierra Wireless. Although the current release lacks a compiled documentation, every public API is properly documented with LuaDoc-compatible comment headers.

Quick overview

Scheduling API

New tasks are created by passing a function to sched.run(). Communication and synchronization are usually best performed through signal emission and monitoring, cf. sched.signal, sched.wait, sched.sigrun etc. for detailled explanations.

For more advanced inter-task communications, check out sched.lock and sched.pipe.

The scheduler is started by calling sched.loop(), which never returns. You must have scheduled at least one task with sched.run before starting the loop, otherwise your program won't do anything.

This scheduler is a collaborative scheduler: it won't preemptively stop a task which never perform any blocking/rescheduling operation. It is not suitable for real-time operations: these must be performed in a separate thread on a real-time process, and then optionally interfaced with Lua for convinience. A rogue task might lock the whole lua_State in which it runs.

Interactive development

Since the loop blocks forever, it prevents interactive development over the usual Lua shell. However, if you start a shell.telnet task, you will be able to interact with a telnet client. For instance, you can connect to a shell launched as below with "telnet localhost 2000":

 require 'sched'
 require 'shell.telnet'

 function main()
     shell.telnet.init{
         address     = '0.0.0.0', 
         port        = 2000,
         editmode    = "edit",
         historysize = 100 }
 end

 sched.run(main)
 sched.loop()

The shell offers history navigation, the usual edition capabilities, and auto-completion. In addition, it supports the following features:

Installation

The external needs are:

This distribution has been successfully tested on Linux 32 and 64 bits. You need to edit the LUA_INC path to Lua headers in the Makefile, then run make.

The LuaSocket port does NOT work under Mac OS X.

You can then either install the result (everything except the c folder, the Makefile, sample.lua and the fetch.lua script) in a Lua directory, or run it directly from the current directory. In the later case, beware that by default, the "./?/init.lua" loader path isn't included in the Lua path. You'll have to do a:

 export LUA_PATH="./?.lua;./?/init.lua"

You can test it with the sample provided:

 $ make
 $ export LUA_PATH="./?.lua;./?/init.lua"
 $ lua sample.lua

Important warnings

This is a preliminary release, in response to interest expressed towards Sierra Wireless' work. APIs are likely to change without regard for backward compatibility.

The scheduler-adapted version of LuaSocket does not work under Mac OS X, for yet uninvestigated reasons.