I have tried more and more, hacking first on libuv c code, but noticed the
problem is somewhere above.
Check here:
http://pastebin.com/ia0G5nwu

Everything happens on rust code, the net_tcp::listen calls on_connect and
on_connect executes, but NEVER returns, it just hangs there.
The last thing that gets printed is "Finishing on_connect".
So, I assume it cannot be uv or net_tcp related, it looks like when
on_connect finishes executing somehow the task hangs in there... maybe some
scheduling or return object copying or something.
Could anybody help me on where could I trace this with GDB? At this point I
am really curious about what the issue is.

--
Arkaitz


On Wed, Oct 24, 2012 at 9:41 AM, [email protected] <[email protected]>wrote:

> Hi,
> I'm starting with rust, although I've been looking inside for a while its
> the first time I try writing real rust code.
> So, I pulled from master yesterday and wrote this simple server
> http://pastebin.com/MMiNpXYG
>
> No tasks, no concurrency, a single-threaded, single-tasked server, that to
> my eyes should be able to handle one client after another, however, I seem
> to be unable to see any other client than the first one in the server,
> netcat does not complain but listen.rs does not see the new client.
> Am I doing anything wrong?
>
> AFAIK, rust is not going to support traditional socket handling,
> everything is going to go over libuv, is this statement correct?
>
> Thanks
>
> --
> Arkaitz
>
_______________________________________________
Rust-dev mailing list
[email protected]
https://mail.mozilla.org/listinfo/rust-dev

Reply via email to