-
Notifications
You must be signed in to change notification settings - Fork 6
/
TODO
46 lines (30 loc) · 2.19 KB
/
TODO
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
To improve the quantity of data available in the VFS it's required to perform
several changes that might be taken into consideration in the future if real
interest will emerge.
Put in every
flom_resource_*.c
a new callback function that returns a piece of RAM VFS with the specific
info of the resource.
For numeric, for example, it will be:
total_quantity
locked_quantity
The main idea is:
in flom_locker.c line 90, inside flom_vfs_ram_tree_add_locker the callback
function on the specific resource will be called and it will give back a list
of files/dirs to put inside the status/lockers/UID dir; brothers and sisters
of "resource_name" and "resource_type". In theory, even them should be part of
the retrieved list of files/dirs.
If the resource must create a dir with files inside it, that will be definitively become more and more complicated...
Possible ideas for future developments, if useful:
implement stack trace feature as implemented by LIXA project
introduce a supplementary module build for Perl and Python to avoid installation before "make check" (verify other bindings like Java too...)
implement a loop for connect/bind if bind returns an error: this should help
to reduce the race condition between a closing daemon and a starting client.
See this thread: https://github.com/tiian/flom/issues/3
Other ideas.....
"object" resources with a state, a memory area, managed by FLoM to transform it in a "state manager" other than a "lock manager"; for flom client, the object will be dumped/restored to/from file
"vector" resources with an associative array of memory areas, managed by FLoM (evolution of "object"; for flom client, the vector will be dumped/restored to/from a zip file or a directory
RESTful interface implemented using Mongoose (?)
replace poll custom based implementation with libevent... (is it interesting?)
put inside function flom_accept_loop_chklockers a check if the thread associated to the locker is really active; if the thread leaved (due to an error), make a clean-up phase. This avoid a daemon crash after a thread terminated with an error, but listener thread has a "locker object" already active
implement FIFO, LIFO, FIRST FIT (for numerical resources) lock allocation policies