Take all code from Asko Kauppi's SVN server, and push it here so that the github repository becomes the official Lanes source codebase.

Note that Asko's SVN server holds version 2.0.9, whereas this is version 2.0.10, but I don't see any real need to update SVN if it is to become deprecated.

Next steps:
- upgrade the rockspec to the latest version
- make the html help available online somewhere

Signed-off-by: Benoit Germain <bnt.germain@gmail.com>

1 files changed, 111 insertions, 0 deletions

diff --git a/BUGS b/BUGS
index d25cc0e..9ae6db5 100644
--- a/BUGS
+++ b/BUGS
@@ -1,6 +1,117 @@
 
 BUGS:
 
+- Reported by Pierre LeMoine (Dec-2009:
+<<
+Hi!
+I think i've located an error in Lanes. When a finalizer is called, it
+receive two tables. The second one seems to be the table containing
+the finalizers. The attached test reproduces the error, and is tested
+on binaries built by myself and from the LfW project.
+The following line from run_finalizers in lanes.c seems to be wrong to me:
+
+   error_index= (lua_rc!=0) ? tbl_index-1 : 0;   // absolute indices
+
+I think it should be -2 there, since the stack at this point should look like
+[-1] finalizer table <- tbl_index
+[-2] stack table
+[-3] error string
+
+Also, in some places, checks for valid returns from lua_toLinda are
+missing, leading to crashes. (for example, linda.get)
+
+Sometimes when i use lanes i get a "recursive use of upvalues"-error,
+i fail to see how upvalues can be recursive? =)
+
+/Pierre
+<<
+
+
+- Reported by Benoit Germain (Dec-2009):
+<<
+Doc says :
+
+The current execution state of a lane can be read via its status member, providing one of these values:
+
+
+"waiting" waiting at a Linda :receive() or :send()
+
+
+
+But code and test say otherwise : lane status remains « running » even when waiting on a Linda operation, which is quite understandable since nowhere in the code status is changed to WAITING. This is a problem for me because my lanes are consumers waiting for commands on a linda. « waiting » status is the only means I have to ensure that a command is not currently being processed. Therefore the fix, to make Lanes behave as the documentation states :
+
+LUAG_FUNC( linda_receive ) {
+        ...
+               // BBB HACK: fetch the lane object to update the status
+               {
+                   struct s_lane *s;
+                   enum e_status prev_status;
+                   STACK_GROW(L,1);
+
+                   STACK_CHECK(L)
+                   lua_pushlightuserdata( L, CANCEL_TEST_KEY );
+                   lua_rawget( L, LUA_REGISTRYINDEX );
+                   s= lua_touserdata( L, -1 );     // lightuserdata (true 's_lane' pointer) / nil
+                   lua_pop(L,1);
+                   STACK_END(L,0)
+                   if( s)
+                   {
+                       prev_status = s->status;
+                       s->status = WAITING;
+                   }
+                   if (!SIGNAL_WAIT( &linda->write_happened, &K->lock_, timeout ))
+                   {
+                       if( s) s->status = prev_status;
+                       break;
+                   }
+                   if( s) s->status = prev_status;
+               }
+
+Of course, the same has to be done in linda_send, and lane structure retrieval could be factorized with the cancel_test. Anyway, what I am concerned about now is whether I missed something or not. Can the lane status change while waiting, so that restoring the previous value could cause problems?
+<<
+
+
+- The use of 'static' and "one time" initialization of things is not suitable
+to a situation where a Lua state is run, using Lanes, then terminated. If
+another Lua state later is launched, the initializations will get cramped.
+
+Reported by Boris Ouretskey (25-Jun-09)
+
+
+- a 'require "lanes"' and speedy exit from the process causes a segfault
+  on ArchLinux (reported by kkndrox@gmail.com 1-Jun-2009). 
+  
+  This issue is not reproducible on Ubuntu (8.04 or 9.04) and has not therefore
+  been fixed. A patch is welcome. The issue is most likely caused by the 
+  Linda thread not being properly launched when the process itself already
+  quits.
+
+<<  
+With Lanes 2.0.3, the following code *always* gives me a segmentation
+fault:
+
+-- begin
+require("lanes")
+-- end
+
+But this:
+
+-- begin
+require("lanes")
+garbagecollect('collect')
+-- end
+
+always work.
+
+Based on this experimentation, if I require lanes and the program end
+without any garbage collecting, I receive a segmentation fault.
+I'm using Arch Linux (32bits), Lua 5.1.4 and it was compiled with gcc 4.3
+<<
+
+    Also simply waiting a bit ('os.execute("sleep 1")') avoids the crash.
+
+
 - tests/irayo_closure.lua fails     (trouble with setting globals right
     for functions carried over to another Lua state)
 
+- "make appendud" causes a segfault on OS X PowerPC.