RE: Asynchronous socket library?

["John Dunn" <John_Dunn@...>]

> bounces@bazar2.conectiva.com.br] On Behalf Of Rob Kendrick
>
> This sounds almost precisely like what LuaSocket provides.  It's a
> higher-level interface than Berkley (very easy to get going with),
> supports non-blocking calls (ie, select), doesn't require you to use
> co-routines, and works on Windows as well as Linux.

The problem is more with the way we plug lua into our application. The
user can define any number of scripts, each of which is loaded into
their own lua_State. The script itself is executed once on startup, and
the user can attach handlers to variable changes ( defined in our own
control engine ) or timer ticks. Script initialization and event
callback have to finish in a predetermined amount of timer or the script
is killed. A script might look something like

-- set the input value to the output, whenever the input changes
function OnInputChanged( control )
  Controls.Outputs[1].Value = control.Value
end

-- attach to first input control
Controls.Inputs[1].EventHandler = OnInputChanged

We also have a timer available -

-- increment the output value each tick
function OnTimerTick()
  Controls.Outputs[1].Value = Controls.Outputs[1].Value + 1
end

Timer.EventHandler = OnTimerTick
-- run timer every 1 sec
Timer.Start(1.0)

So the script is really an initialization script that attaches a bunch
of handlers to events - it's sorta similar to what scripting a GUI might
look like. The handlers are called from C using lua_pcall. 

The user could implement a state machine in a timer handler which used
LuaSockets and select so it could return quickly. I've also played with
using coroutines inside our timer handler and that works as well. 

function OnTimer()
  while true do
    print("odd")
    coroutine.yield()
    print("even")
    coroutine.yield()
  end
end

co = coroutine.create(OnTimer)

Timer.EventHandler = function() coroutine.resume(co) end
Timer.Start(1)

My main issues with these approaches is that the script would look
pretty ugly and if the user passed the wrong arguments to the Socket
calls it would be possible to 'wedge' the script. The nice thing about
the truly asynchronous model is the user can't screw things up.