Well, in a real example where the server did actual work for each socket, concurrency would clearly be desirable, since you need a task for the actual work and another task to listen for new connections (and presumably a fresh task for each connection, to do the actual work.)
But I agree that this seems non-ergonomic in its current form. Glenn On Oct 25, 2012, at 4:19 PM, [email protected] wrote: > 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 > > > > _______________________________________________ > > Rust-dev mailing list > > [email protected] > > https://mail.mozilla.org/listinfo/rust-dev > > > > > > !DSPAM:50895448316022347716413! > > > !DSPAM:50899dac130302097917617!
PGP.sig
Description: This is a digitally signed message part
_______________________________________________ Rust-dev mailing list [email protected] https://mail.mozilla.org/listinfo/rust-dev
