forked from backtracking/functory
-
Notifications
You must be signed in to change notification settings - Fork 0
/
Copy pathTODO
58 lines (35 loc) · 1.7 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
47
48
49
50
51
52
53
54
55
56
57
58
- low-level API: remove_task
- Cores: use pipes instead of local files (and thus select instead of wait)
and compare performances
- Cores: flush stdout and stderr before fork, to avoid duplicating
user messages
- more fault tolerance:
master should not be blocked when sending a huge data to a worker
which is not reading (e.g. the worker is suspended or unreachable)
solution: instead of using Unix.write which behaves as an atomic
operation (possibly blocking), write our own loop using select with
a timeout; when it timeouts, close the connection to that worker
- try Mandelbrot with Same
- make an experiment with different OS
- check consistency of executables (md5 checksum)
- acknowledgment for killed message: use Aborted for that purpose
- minimal API (map, fold, etc.)
. map : ...
. reduce : (a -> b) -> (c -> b -> c) -> c -> a list -> c
assumption : the order of elements in the list is irrelevant
variants : local/remote reduce
. reduce2 : (a -> b) -> (b -> b -> b) -> b -> a list -> b list
assumption : reduce is AC
variant : reduce is A but not C
(still we can parallelize some adjacent reductions)
- make Str generic wrt a type t together with 2 functions to/from_string
- refactor map, etc. in Cores/Network
- make the master more robust [fault tolerance]
- pinging workers (a separate list for not responding workers)
- (re-)scheduling heuristics
- how to change the port number (either Control.set_port / environment variable)
BUGS ?
- using localhost as a worker
- do we need to shutdown sockets eventually?
(currently we don't do it, because we don't know when to do it,
unless we are using at_exit --- but we can't use at_exit!)