1 files changed, 0 insertions, 71 deletions

diff --git a/BUGS b/BUGS
index 9ae6db5..af9b0ae 100644
--- a/BUGS
+++ b/BUGS
@@ -1,76 +1,5 @@
-
 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.