TODO
3.2 KB
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
VERY BIG TODO:
- right now i will use long polling ajax calls when feedback from to the client
is needed. In the long term this should be changed to websockets (ws). But
right now ws specification is not final anyway. :)
- handle errors after all system call...especially open, close, etc.
- IPV6 support
- There seem to be a problem in the server under heavy load. Some tests with ab show that at some point it does not accept any more connections. Nor does it seem to answer request. I guess that it might be difficult to find this....
=> might be done... maybe not completely, I still loose connections under very high load.
- using tsearch for my memory management was kind of a bad idea. tsearch uses malloc and free upon addition and remove of elements. Resulting again in uncontroolled heap usage. I guess I have to implement my own tree mechanism here, which does not involve further allocation.
- another bug: if there is trailing garbage on the header line
we got a segfault...
GET /images/waldschrat.jpg HTTP/1.1^[[D^[[D^[[D^[[D^[[D^[[D^[[D^[[D^[[D^[[D^[[D^[[D^[[D^[[D
^[[D = backspace...
- the unexpected connection close seems to occur just on concurrency over
1000 paralell connections...maybe this gives a hint.
- after changing to non blocking sockets the server hangs after some requests.
have to check when this happens....
* it seems that it does not occur without keep-alive and concurrency
* also concurrent connection don't seem to make a problem.
* keep-alive alone again don't seem to be a problem...
!!!! if both are active something is screwed up.... !!!!
- at least some of the problems result in something that I think
is a bug in the glibc implementation of tdelete.
Under some circumstances tdelete does not search the whole tree.
Here comes some debug output of the code...
This shows a code fragment that tries to remove a no longer
needed asset from the asset_pool.
DEBUG: pool release asset --./assets/image/waldschrat.jpg--
Twalk over all elements in the tree:
DEBUG: ./assets/image/waldschrat.jpg(1910357807899405601) => 0xe378a8
DEBUG: ./assets/js/jquery.js(10519512221325982142) => 0x10d3638
Output of each call to tDelete comparison function:
(Notice that the searched asset hash was in the previous Twalk.
DEBUG: search asset hash: 1910357807899405601
DEBUG: found: 10519512221325982142, key: ./assets/js/jquery.js
DEBUG: !!!!! NOT FOUND !!!!!!!
DEBUG: find results in (nil)
Repeated 2 times if non was found...
DEBUG: search asset hash: 1910357807899405601
DEBUG: found: 10519512221325982142, key: ./assets/js/jquery.js
DEBUG: !!!!! NOT FOUND !!!!!!!
DEBUG: find results in (nil)
DEBUG: search asset hash: 1910357807899405601
DEBUG: found: 10519512221325982142, key: ./assets/js/jquery.js
DEBUG: !!!!! NOT FOUND !!!!!!!
DEBUG: find results in (nil)
===
Again a twalk over all elements...
DEBUG: ./assets/image/waldschrat.jpg(1910357807899405601) => 0xe378a8
DEBUG: ./assets/js/jquery.js(10519512221325982142) => 0x10d3638
Final statement...
DEBUG delete 0xe378a8, parent was (nil)
So, it looks like I should build my own tree implementation...
well in fact it seems that I have to!