lua-users home
lua-l archive

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index]


>
> I had a glimpse of the code. I like the idea of M:N schedule.
>
> I see the ``select, send, recv`` functions mimics the sockets, but
> only in a non-blocking style. is there a plan to add some blocking
> synchonization mechanism (e.g. call `yield` inside send or recv)?
>

If select returns nil (no channels can read), it will set the status
of task to BLOCKED,
and the following coroutine.yield() will block.

You can use a few lines of lua  code to  wrap a blocking recv like this :

https://github.com/cloudwu/ltask/blob/master/consumer.lua

function recv()
  while true do
    if ltask.select(c) then
        local ok, value = ltask.recv(c)
        if ok then
            return value
        end
    end
     coroutine.yield()
   end
end

> I also noticed your packing/unpacking (or serialization/deserialization)
> code have limitations on the data structure. I would like it to have support
> for, at least, Lua functions with no (explicit) upvalues and tables having
> entries refered to same object.
> or, maybe you could take use of some existing serialization modules.

You can use your  serialization modules , and send the serialized
string or lightuserdata.

> one last thought is the single schedule struct might hurt the scalability.
> I see read-write lock is used to protect the shared queue.
> if this code is to be used in very large parallel systems, I'd suggest some
> lock free algorithms.

The queue haven't use read-write lock, it uses a simple spin-lock.
I don't think the lock free queue would be better here, but more complex.

-- 
http://blog.codingnow.com