mirror of https://github.com/lukechilds/node.git
You can not select more than 25 topics
Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
88 lines
3.7 KiB
88 lines
3.7 KiB
- 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
|