Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
net_tcp read timeout #3599
Not completely sure if this is a bug because I'm finding it difficult to figure out how to use net_tcp using the unit tests. But the below code times out when both the client and the server try to read.
Logging shows this:
So it appears the the message is being read but the read function isn't returning for some reason (the first message is "dupe: hey\0" which is 10 bytes). This is on Mac with rust from Sep 22, 2012.
The seg faults are a bit disturbing too...
I should have responded to this before. Preemptive apology: this interface is not so good.
The problem here may be in accepting and handling the connection in the on_connect callback. That callback runs directly on the I/O loop, so doing long running operations in that callback will block all I/O entirely. The way it's intended to be used is to delegate the accepting and handling of the connection to another task, but there are some wrinkles.
You can't just call
Additionally, a connection has to be 'accepted' before the on_connect callback returns, but calling
What you have to do is set up another task to handle the acceptance of connections.
Here's an example of a working TCP server and client, more readable than the TCP test cases: brson@fcfdd49#L0R789
I'm still having problems with this, using a sample similar to issue #4296.
My intention is to implement a simple TCP server to start implementing some higher-level protocols like FastCGI for Rust, so any efforts to move this forward would be highly appreciated :-)
I assume the updated example @brson provided refers to this test:
I removed the flatpipes specific code and some other code that seemed unneeded to make as basic of an example as I could. The Receiver task is needed because if that code is in the on_connect callback it blocks.
I share @mneumann's concern that the idea behind libuv is to use an event loop and not threads. Two tasks/threads might be acceptable, but the only way I could get an echo server to work with multiple connections was spawning a task for each connection.
Seems to me that