1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
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.
|
