I agree with the desirable concurrency, but this should be orthogonal with what the server does, and as such, I understand a desirable implementation wouldn't need it, fastest http servers in the internet are monothread and not concurrent. Truth is with light tasks like in rust you would just spawn task/client anyway.
-- Arkaitz On Thu, Oct 25, 2012 at 10:22 PM, Glenn Willen <[email protected]> wrote: > 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! > >
_______________________________________________ Rust-dev mailing list [email protected] https://mail.mozilla.org/listinfo/rust-dev
