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
|
- Implement setenv / unsetenv
- Implement other stuff missing in node.cc/process
Like getuid, getgid, setgid, kill etc.
- Better `net` support
* getaddrinfo
* setMulticastTTL, setMembership, setLoopback
* pipe, socketpair
* A named pipe should be provided when a unix socket is requested.
* SendMsg and RecvMsg should be supported with named pipes.
- New libev backend
The current libev backend supports sockets only. This complicates stuff like
child processes, stdio. Best would be if node_net switched from exposing
readyness notifications to using completion notifications, so on windows we
could use IOCP for sockets. Experts tell me that is really the fastest way
to work with sockets on windows.
- Child process issues
* Communication between parent and child is slow; it uses a socketpair
where a pipe would be much faster. Replace it by a pipe when there
is a libev backend that supports waiting for a pipe.
* When a child process spawns the pid is not available straightaway.
On linux the pid is available immediately because fork() doesn't
block; on windows a libeio thread is used to call CreateProcess.
So this can't really be fixed, but it could be worked around by adding a
'spawn' or 'pid' event.
* passing socket custom_fds is not supported
* child_process.exec() only works on systems with msys installed.
It's because it relies on the 'sh' shell. The default windows shell
is 'cmd' and it works a little differently. Maybe add an option to
specify the shell to exec()?
- Make colorful util.inspect work on windows.
- Stdio: support passing sockets between master/child process
Normal windows applications wouldn't like this, but it can be useful for
communication between node processes. This requires
stdio.isStdinBlocking/isStdoutBlocking to be smarter.
- Skip/fix tests that can never pass on windows
- Find a solution for fs.symlink / fs.lstat / fs.chown
Windows has different symlink types: file symlinks (vista+),
directory symlinks (vista+), junction points (xp+)
- Handle _open_osfhandle failures
E.g. currently we're using the construct _open_osfhandle(socket/open/accept(...)).
Now socket() can fail by itself and _open_osfhandle can fail by itself too.
If socket() fails it returns -1 so _open_osfhandle fails as well, but and we'll always return/throw EBADF.
If _open_osfhandle fails but socket doesn't, a stray handle is left open. It should be fixed.
- Think about `make install`
- Extensions
Should be DLLs on windows.
- Link pthreads-w32 statically by default
- Link Mingw libraries statically by default
Like libstdc++.dll, more maybe.
Microsoft libs are always there, no static linkage required (e.g. msvcrt, winsock2).
- Make (open?)SSL work
- Support using shared libs (libeio, v8, c-ares)
Need to link with with a stub library. Libraries should use `dllexport`,
headers must have `dllimport`.
- V8: push MINGW32 build fixes upstream
- Work around missing pread/pwrite more elegantly
Currently it's exported from libeio, while it wasn't intended to be exported.
The libeio workaround implementation sucks, it uses a global mutex.
It should be possible to implement pread and pwrite using winapi's ReadFile/Writefile
directly, passing an OVERLAPPED structure while not associating with an completion port.
- Work around missing inet_pton/inet_ntop more elegantly
Currently it's exported from from c-ares, while it wasn't intended to be exported.
It prevents linking c-ares dynamically.
- See what libev/libeio changes can be pushed upstream
- 64-bit build
Should be possible with MinGW-w64, it's pretty good.
- ... much more probably
|
