Hi, After some hours of hacking around finally pinpointed it in the destructor as you guessed it, I was mislead by an example where the accept wasn't being called and actually libuv was blocking the rest because its kind of low level interface here where it gives you a non accepted event on the listen port, so you are expected to accept always or obviously the client will remain the backlog of the listen port. But this is another story.
What happens here, thanks to Niko Matsakis for helping me in the IRC, is that you cannot destroy a socket from the same thread where you run listen, basically the IO thread. There is a message exchange between the destructor and the listens task which obviously never finishes when they are in the same thread. So, the solution seems to be to spawn the listen in a different scheduler but then pass the sockets to their handlers spawning tasks in the main scheduler. This situation doesn't look ideal to me and I don't think its intuitive but seems to be the way to go for the moment in rust. Apparently a better/easier listen could be written on std::net::tcp that returns accepted sockets, but I am not too sure how would that play with the messaging destructor. To my eyes it should be possible to write a server without spawning any task since no concurrency is really needed, but things are like that atm. -- Arkaitz On Thu, Oct 25, 2012 at 10:07 PM, Glenn Willen <[email protected]> wrote: > There's something weird going on in the original Rust example. > > The flow of control seems to never be leaving the 'if result.is_ok()' > block. I suspect 'socket' has a blocking destructor that's hanging the task > until the socket is closed. That would explain why it would work if a new > task is spawned. > > Can someone familiar with the socket internals confirm that this is what's > happening? > > It is interesting that this kind of blocking behavior is possible. Is it > considered desirable? It's certainly non-intuitive. The same thing is > certainly possible in C++ (though not in Java where finalizers are > asynchronous.) I think it would be bad form there for a destructor to > block, though. > > Glenn > > On Oct 25, 2012, at 11:05 AM, [email protected] wrote: > > > 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 > > > > !DSPAM:50895448316022347716413! > _______________________________________________ > > Rust-dev mailing list > > [email protected] > > https://mail.mozilla.org/listinfo/rust-dev > > > > > > !DSPAM:50895448316022347716413! > >
_______________________________________________ Rust-dev mailing list [email protected] https://mail.mozilla.org/listinfo/rust-dev
