From 282f59ca02d1d1f304b9126b84a8b1427caf3172 Mon Sep 17 00:00:00 2001 From: benoit-germain Date: Fri, 14 Sep 2012 11:47:19 +0300 Subject: removed fixed BUGS entries --- BUGS | 71 -------------------------------------------------------------------- 1 file changed, 71 deletions(-) (limited to 'BUGS') 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. -- cgit v1.2.3-55-g6feb