lua-users home
lua-l archive

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


> socket.http uses a function called protect(), which uses
> pcall. There is a sample pair in the LuaSocket distribution
> that works around this problem by redefining protect(). Take
> a look at dispatch.lua and check-links.lua.  Not sure how
> this would interact with COPAS, but might be worth it a try.

It doesn't look like it will work with COPAS. COPAS receive and send will
yield, if the I/O would block and the yield assumes it's returning values
to the COPAS scheduler. If you wrap a LuaSocket with coxpcall, coxpcall
will probably catch errors, but will also end up getting the yields from
the COPAS functions. At least this is how I see it now, based on my
limited understanding of how the coroutine-based xpcall is supposed to
work.

If you are supporting HTTP requests within your HTTP server (maybe you
want to act as a proxy or you want to  pass information from another
server for other reasons), not having non-blocking HTTP means that
whenever you are doing this, your HTTP server is going to go down the
drain, as its only execution thread will be blocked by outgoing HTTP
request.

How hard this will be to fix depends on how much socket.http relies on
pcalls to do error handling. My own programming background is such that
I've never liked setjmp/longjmp style error handling.

I'm still hoping that I will be able to use LuaSocket along with COPAS
(possibly with modifications to both) to implement what I need. It already
appears to be working, but I would bet that the error handling that used
to be done with pcall is currently not working, so I'll probably have a
look at that this afternoon.

-- 
Juri Munkki