<sb0>
larsc, I think this is may be unnecessary, you can take out the clocks from transceivers into the fabric without problems. the only thing I see is problems with sampling sysref, as there may be issues with jitter or divider. the JESD logic should be insensitive to that. how does one need to sample sysref, and where did you read about the 6.6Gbps limit?
<sb0>
what I want eventually is send what is received on one connection to all connections
<whitequark>
sb0: so the most important thing to understand about rust memory management is the concept of ownership
<whitequark>
for an unadorned thing (i.e. without Rc<>, Arc<>, or other similar sharing mechanism) there is exactly one place it is stored, and that place is responsible for destroying it
<whitequark>
when you want to do something with a thing stored there, you have two options
<whitequark>
first, you can borrow it, and second, you can take it out (i.e. move)
<whitequark>
in this case, you want the LinkedList to keep storing the connections (presumably) and so you want to borrow it
rohitksingh has joined #m-labs
<whitequark>
the way you can borrow every item in a LinkedList sequentially is by doing for conn in list.iter() { ... }
<whitequark>
... or in this case, .iter_mut(), since reading or writing from a connection requires exclusive access.
<whitequark>
the &mut pointer is somewhat of a misnomer. it says "mutable" but what it really means is "exclusive"
<sb0>
yes, I read that in the doc
<whitequark>
ok
<sb0>
but now I have the problem that I do want the same object in two places: the linked list so I can broadcast, and where the connection is accepted so I can read what to broadcast
<whitequark>
are you trying to make something like an ethernet hub (but for TCP connections) ?
<sb0>
yes
<whitequark>
ahh
<sb0>
no practical use, just trying out rust
<whitequark>
so in std::io::TcpStream, you have a .clone()
<whitequark>
this gives you another view into the same file descriptor, essentially
<whitequark>
this doesn't exist with the io scheduler I wrote since it simply lacks that layer of indirection
<whitequark>
I've considered adding it but decided to save time and do without, since it's not really necessary for any of the code I'll need to port
<whitequark>
anyway, you can work around that, one sec
<whitequark>
sb0: put the TcpStream into an Rc<RefCell<...>>
<whitequark>
then you could do something like... rc_conn.borrow().write(b"jjj")
<whitequark>
borrow_mut() rather
<sb0>
I'm running on linux for now
<whitequark>
ah, then just clone()
<sb0>
let me try clone()
<sb0>
do we have linkedlists and the other things in the standard library on the device?
<whitequark>
yes, you have all of the collections
<whitequark>
you don't have anything in std::sync or std::io
<sb0>
hm, i'm using mioco and it doesn't have clone()
<whitequark>
no idea what to do with mioco
<whitequark>
I haven't really found mio necessary so far. there's a reason Rust dropped green threads from the core language, too
<sb0>
does this have anything to do with the problem I have right now?
<sb0>
src/main.rs:24:15: 24:27 error: the trait bound `std::rc::Rc<std::cell::RefCell<mioco::MioAdapter<mio::net::tcp::TcpStream>>>: std::marker::Send` is not satisfied [E0277]
<whitequark>
so the error above essentially says that Rc cannot be shared between threads (since it's not threadsafe)
<whitequark>
Arc is
<sb0>
anyway, try_clone seems to work
<sb0>
ok, but this is supposed to be a coroutine
<whitequark>
sure
<whitequark>
that's still a concurrency primitive
<whitequark>
sb0: there are multiple reasons, but I think the main one is that mioco explicitly lets you use multiple thread for dispatch
<whitequark>
i.e. the same number of threads as the number of cores
<sb0>
hm, now I can't use the linked list in the coroutine
<whitequark>
yes. you need to put that into Arc<Mutex<...>>
<sb0>
which makes senses if it were a thread, but now it's simply annoying
<whitequark>
it has the same problems as threads...
<sb0>
how do I iterate on a mutex-protected linked list?
rohitksingh has quit [Ping timeout: 244 seconds]
<sb0>
for conn2 in connections.lock().unwrap() results in
<sb0>
src/main.rs:28:21: 30:22 error: the trait bound `std::sync::MutexGuard<'_, std::collections::LinkedList<mioco::MioAdapter<mio::net::tcp::TcpStream>>>: std::iter::Iterator` is not satisfied [E0277]
<whitequark>
.unwrap().iter()
<whitequark>
MutexGuard dereferences to its contents, so it acts much like a &mut LinkedList would
<sb0>
back to the original error I had before any arc/mutex stuff. it refuses to move the Arc<Mutex<LinkedList>>> into the closure just like it refused to move LinkedList
<whitequark>
yes
<whitequark>
but now you can clone the Arc
<whitequark>
leave one copy where it is, move the other