aboutsummaryrefslogtreecommitdiff
path: root/BUGS
diff options
context:
space:
mode:
authorbenoit-germain <bnt.germain@gmail.com>2012-09-14 11:47:19 +0300
committerbenoit-germain <bnt.germain@gmail.com>2012-09-14 11:47:19 +0300
commit282f59ca02d1d1f304b9126b84a8b1427caf3172 (patch)
tree90d1b7929e3731d501e4f435132af7cd312bbbfe /BUGS
parent30b046f829541ae5ff8dc1088cea8e09bdc320db (diff)
downloadlanes-282f59ca02d1d1f304b9126b84a8b1427caf3172.tar.gz
lanes-282f59ca02d1d1f304b9126b84a8b1427caf3172.tar.bz2
lanes-282f59ca02d1d1f304b9126b84a8b1427caf3172.zip
removed fixed BUGS entriesv3.3.0
Diffstat (limited to 'BUGS')
-rw-r--r--BUGS71
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 @@
1
2BUGS: 1BUGS:
3 2
4- Reported by Pierre LeMoine (Dec-2009:
5<<
6Hi!
7I think i've located an error in Lanes. When a finalizer is called, it
8receive two tables. The second one seems to be the table containing
9the finalizers. The attached test reproduces the error, and is tested
10on binaries built by myself and from the LfW project.
11The following line from run_finalizers in lanes.c seems to be wrong to me:
12
13 error_index= (lua_rc!=0) ? tbl_index-1 : 0; // absolute indices
14
15I think it should be -2 there, since the stack at this point should look like
16[-1] finalizer table <- tbl_index
17[-2] stack table
18[-3] error string
19
20Also, in some places, checks for valid returns from lua_toLinda are
21missing, leading to crashes. (for example, linda.get)
22
23Sometimes when i use lanes i get a "recursive use of upvalues"-error,
24i fail to see how upvalues can be recursive? =)
25
26/Pierre
27<<
28
29
30- Reported by Benoit Germain (Dec-2009):
31<<
32Doc says :
33
34The current execution state of a lane can be read via its status member, providing one of these values:
35
36
37"waiting" waiting at a Linda :receive() or :send()
38
39
40
41But 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 :
42
43LUAG_FUNC( linda_receive ) {
44 ...
45 // BBB HACK: fetch the lane object to update the status
46 {
47 struct s_lane *s;
48 enum e_status prev_status;
49 STACK_GROW(L,1);
50
51 STACK_CHECK(L)
52 lua_pushlightuserdata( L, CANCEL_TEST_KEY );
53 lua_rawget( L, LUA_REGISTRYINDEX );
54 s= lua_touserdata( L, -1 ); // lightuserdata (true 's_lane' pointer) / nil
55 lua_pop(L,1);
56 STACK_END(L,0)
57 if( s)
58 {
59 prev_status = s->status;
60 s->status = WAITING;
61 }
62 if (!SIGNAL_WAIT( &linda->write_happened, &K->lock_, timeout ))
63 {
64 if( s) s->status = prev_status;
65 break;
66 }
67 if( s) s->status = prev_status;
68 }
69
70Of 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?
71<<
72
73
74- The use of 'static' and "one time" initialization of things is not suitable 3- The use of 'static' and "one time" initialization of things is not suitable
75to a situation where a Lua state is run, using Lanes, then terminated. If 4to a situation where a Lua state is run, using Lanes, then terminated. If
76another Lua state later is launched, the initializations will get cramped. 5another Lua state later is launched, the initializations will get cramped.