harningt / luaevent Goto Github PK

Lua 5.3 does not have lua_equal (neither did Lua 5.2), however the feature flag checks only for Lua 5.2.

Your all target currently unconditionally compiles everything everytime it is called, for example from the install target. This prevents build and install from being two different steps of the build process, which breaks some packaging tools for example.

A good solution for this problem would be to add targets for core.so depending on all .o files, and list it as a dependency for the all target, so if core.so is already present it won’t get built again.

Commit ced1f0d does not properly balance the Lua stack, and as a result values accumulate on every callback until Lua eventually throws a "stack overflow" error.

The actual stack limit depends on a compile-time macro in Lua, so it's hard to provide a decent test case. However the leak can be easily inspected by printing lua_gettop(L) within the luaevent_callback() function, and observing that it increases with every call.

I have a patch to fix the issue which I'll submit as a PR.

When using the "return a new timeout" feature implemented in event_callback.c, timeouts of 0s are converted to a NULL timeout (which means block forever). This is inconsistent with the addevent code in luaevent.c, which allows you to set a 0s timeout.

This patch fixes the issue:

--- a/src/event_callback.c  2015-12-17 13:22:07.150902699 +0000
+++ b/src/event_callback.c  2015-12-17 13:22:22.966738099 +0000
@@ -52,8 +52,6 @@
        if( newEvent != event || (cb->timeout.tv_sec != new_tv.tv_sec || cb->timeout.tv_usec != new_tv.tv_usec) ) {
            struct timeval *ptv = &cb->timeout;
            cb->timeout = new_tv;
-           if(!cb->timeout.tv_sec && !cb->timeout.tv_usec)
-               ptv = NULL;
            event_del(ev);
            event_set(ev, fd, EV_PERSIST | newEvent, luaevent_callback, cb);
            /* Assume cannot set a new timeout.. */

LuaSocket has an intermediate buffer for incoming data. When one calls conn:read(n), n bytes of data will be returned from this buffer, which is refilled from the underlying socket in 8k blocks (BUF_SIZE in buffer.h).

My guess is that this is to reduce the number of syscalls

However, because LuaEvent isn't aware of this buffer, this has the unfortunate side-effect that if you read less than BUF_SIZE, there may still be data left and no new read event will fire until new data comes in from the network.

A workaround is to always read everything, eg by :read()-ing "*a" or BUF_SIZE bytes.

I'm encountering difficulties installing luaevent on Debian Bookworm with Lua 5.4. When attempting to install it using luarocks, I receive the following error message:

$ luarocks install luaevent
Error: No results matching query were found for Lua 5.4.

The project could not be analyzed because of maven build errors. Please review the error messages here. Another build will be scheduled within 24 hours. If the build is successful this issue will be closed, otherwise the error message will be updated.

_{This is an automated GitHub Issue created by Sonatype DepShield. GitHub Apps, including DepShield, can be managed from the Developer settings of the repository administrators.}

Travis-CI needs test builds for various version combinations.

In the luaevent.lua script file, there is an attempt to set the '__mode' attribute of to 'kv' in order to enable automatic collection for luaevent elements, however the syntax is wrong:

setmetatable({}, {'__mode', 'kv'})

should be

setmetatable({}, {__mode = 'kv'})

Upon review, this part of the system needs rework.

lauevent.h references event.h, which is not in this distribution.