-
Notifications
You must be signed in to change notification settings - Fork 38
Add tcp servers and clients to standard library #1058
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: master
Are you sure you want to change the base?
Conversation
0753152
to
3349353
Compare
Perhaps the other leak is the same as this one: libuv/libuv#559 |
Looks indeed similar, I believe the 128 byte object to be some internal UV structure. |
The space leak was a stack that does not get freed when using |
523a4bb
to
ca3926a
Compare
5b0382e
to
bdcaf73
Compare
/// A TCP handle. Should not be inspected. | ||
type Connection = Int |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
/// A TCP handle. Should not be inspected. | |
type Connection = Int | |
/// A TCP handle. Should not be inspected. | |
extern type Connection | |
// = llvm "Int" |
Could we make it an extern type so that it cannot be inspected?
(also applies to Listener
below)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, I don't like it (because then it is a Pos
) but I guess I'll have to do it, because the representation in js
is different.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Approaching the problem from the other side: does it have to be a Pos
? We could let the user choose, no?
Couldn't we fix this "properly" by some = llvm "i64"
annotation there instead? 🎣
This fixes a memory leak and increases the backlog of uv_listen to SOMAXCONN, such that connections are put in a queue when the previous acceptor is not yet finished (this is the case with a timeout, which triggers the connects at the same time) Another memory leak remains which I couldn't find. ``` ==130847== 128 bytes in 1 blocks are definitely lost in loss record 1 of 1 ==130847== at 0x48577A8: malloc (vg_replace_malloc.c:446) ==130847== by 0x4003F90: ??? (in server_client) ==130847== by 0x4004499: ??? (in server_client) ==130847== by 0x4004557: run (in server_client) ==130847== by 0x4004A1C: spawn_4055 (in server_client) ==130847== by 0x40044F6: resume_Int (in server_client) ==130847== by 0x4002BA0: c_tcp_listen (io.c:367) ==130847== by 0x4004B65: listen_4331 (in server_client) ==130847== by 0x400CA5D: effektMain (in server_client) ==130847== by 0x4003D60: main (main.c:37) ```
bdcaf73
to
ca34e62
Compare
server_client
and more than 2 clientsThe web does not support TCP and for Node this API is too low level. If we wanted to create node servers eventually, we would wrap a more high-level API.