[rust-dev] How to end a task blocked doing IO

2014-03-07 Thread Rodrigo Rivas 
Hello!

I'm writing my first non trivial program in Rust and I'm facing now a
blocking issue (pun intended): I have to read/write data from/to a
TcpStream, so I create a task for reading and a task for writing.

fn do_tcp_stuff(sck : TcpStream) {
let mut wtr = ~BufferedWriter::new(sck.clone());
let mut rdr = ~BufferedReader::new(sck);

let (inport, inchan) = Chan::new();
let (outport, outchan) = Chan::new();

spawn(proc() { do_tcp_write(wtr, outport); });
spawn(proc() { do_tcp_read(rdr, inchan); });

loop {
   // do interesting things, select!() and such
}

}

fn do_tcp_write(mut wtr : ~Writer, port : Port~[u8]) - IoResult() {
loop {
let data = port.recv();
try!(wtr.write(data));
wtr.flush();
}
Ok(())
}

fn do_tcp_read(mut rdr : ~Reader, chan : Chan~[u8]) - IoResult() {
loop {
let block = try!(rdr.read_bytes(1024));
chan.send(block);
}
Ok(())
}

And all works perfectly... until I want to close the connection and
kill the tasks:

- The do_tcp_write() function is blocked in port.recv(), so if I
close the outchan it will finish automatically. Nice!
- But the do_tcp_read() function is blocked in rdr.read_bytes() so
closing inport will not affect it, unless it happens to receive some
data.

I've read that in older iterations of the library I could use linked
tasks or something like that. But in master that seems to have
disappeared. I tried also closing the connection, but I couldn't find
how.

Is there any way to do what I want? Or am I doing something fundamentally wrong?

Thank you in advance for your help!
-- 
Rodrigo
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev

Re: [rust-dev] How to end a task blocked doing IO

2014-03-07 Thread Kevin Ballard 
AFAIK there is no solution to this at the moment.

One proposal was to add a `close()` method to `TcpStream` that would close it 
immediately without waiting for it to go out of scope. This seems like the 
simplest solution, if someone wants to implement it.

A better (but much more complicated) solution is to have a Select functionality 
that allows for handling Channels and TcpStreams at the same time. That’s 
something a bunch of us want, but it’s more complicated to implement.

-Kevin

On Mar 7, 2014, at 3:04 PM, Rodrigo Rivas rodrigorivasco...@gmail.com wrote:

 Hello!
 
 I'm writing my first non trivial program in Rust and I'm facing now a
 blocking issue (pun intended): I have to read/write data from/to a
 TcpStream, so I create a task for reading and a task for writing.
 
 fn do_tcp_stuff(sck : TcpStream) {
let mut wtr = ~BufferedWriter::new(sck.clone());
let mut rdr = ~BufferedReader::new(sck);
 
let (inport, inchan) = Chan::new();
let (outport, outchan) = Chan::new();
 
spawn(proc() { do_tcp_write(wtr, outport); });
spawn(proc() { do_tcp_read(rdr, inchan); });
 
loop {
   // do interesting things, select!() and such
}
 
 }
 
 fn do_tcp_write(mut wtr : ~Writer, port : Port~[u8]) - IoResult() {
loop {
let data = port.recv();
try!(wtr.write(data));
wtr.flush();
}
Ok(())
 }
 
 fn do_tcp_read(mut rdr : ~Reader, chan : Chan~[u8]) - IoResult() {
loop {
let block = try!(rdr.read_bytes(1024));
chan.send(block);
}
Ok(())
 }
 
 And all works perfectly... until I want to close the connection and
 kill the tasks:
 
 - The do_tcp_write() function is blocked in port.recv(), so if I
 close the outchan it will finish automatically. Nice!
 - But the do_tcp_read() function is blocked in rdr.read_bytes() so
 closing inport will not affect it, unless it happens to receive some
 data.
 
 I've read that in older iterations of the library I could use linked
 tasks or something like that. But in master that seems to have
 disappeared. I tried also closing the connection, but I couldn't find
 how.
 
 Is there any way to do what I want? Or am I doing something fundamentally 
 wrong?
 
 Thank you in advance for your help!
 -- 
 Rodrigo
 ___
 Rust-dev mailing list
 Rust-dev@mozilla.org
 https://mail.mozilla.org/listinfo/rust-dev

___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev

[rust-dev] Why duplicate `libstd-31b43f22-0.10-pre.so` both in `/usr/local/lib` and `/usr/local/lib/rustlib/xxx/lib`?

2014-03-07 Thread Liigo Zhuang 
Hey Rusties:

Could we remove the one in `rustlib`, and let `rustc` reuse the one in
'/usr/local/lib'?
If we could do this, the distribution package will be much smaller.
`rustc` is run only in host environment, right?

(Another option, static link rustc, and remove all *.so in rustlib.)

Liigo.
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev

Re: [rust-dev] Why duplicate `libstd-31b43f22-0.10-pre.so` both in `/usr/local/lib` and `/usr/local/lib/rustlib/xxx/lib`?

2014-03-07 Thread Daniel Micay 
On 07/03/14 10:53 PM, Liigo Zhuang wrote:
 Hey Rusties:
 
 Could we remove the one in `rustlib`, and let `rustc` reuse the one in
 '/usr/local/lib'?
 If we could do this, the distribution package will be much smaller.
 `rustc` is run only in host environment, right?
 
 (Another option, static link rustc, and remove all *.so in rustlib.)
 
 Liigo.

The `rustdoc` binary also uses librustc and third party tools may want
to use them as they mature into saner libraries, so I don't think static
linking is a good option.

The stable/nightly Arch Linux packages (`rust` and `rust-git`) symlink
away the duplication as the ABI has always been the same for some time.
I've never actually seen stage1/stage2 configuration markers used.



signature.asc
Description: OpenPGP digital signature
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev