<JamesMunns[m]>
I guess that's "read_exact", but maybe that helps :D
<JamesMunns[m]>
ah, shoot!
<atesterlol[m]>
im not executing read
<atesterlol[m]>
im using io::copy which executes the read method of a struct which implements Read
<atesterlol[m]>
in this implementation im calling read of a specific member of the struct. the problem is it stops suddenly even tho there is more space at the buffer
<dirbaio[m]>
(there are some specializations if both src and dst are files or sockets or something, but they definitely won't apply to your "decrypting Read" wrapper)
<atesterlol[m]>
dirbaio[m]: there is actually some magic
<atesterlol[m]>
it reduces half of the syscalls i need
<dirbaio[m]>
this magic doesn't apply with custom Read impls
<atesterlol[m]>
it does since my Read method uses sockets
<dirbaio[m]>
it only applies if src and dst are both plain old fd's
<atesterlol[m]>
* since my `Read, * Read` method
<atesterlol[m]>
s/Read/`read`/
<dirbaio[m]>
if you wrap the reader with your own Read implementation written in plain old rust, it's not a plain old fd anymroe
<dirbaio[m]>
s//`/, s//`/, s/anymroe/anymore/
<dirbaio[m]>
and the magic no longer kicks in
<atesterlol[m]>
it relies on the implementation of my socket
<dirbaio[m]>
¯\_(ツ)_/¯
<dirbaio[m]>
just benchmark it when you're done implementing, you'll see what I mean
<atesterlol[m]>
i also did benchmark it
<JamesMunns[m]>
I think though the long answer to your question is that "there is no way to force read to always return in some increments".
<atesterlol[m]>
got twice as fast
<JamesMunns[m]>
the way to do it is to wrap it, and use a buffered reader or something
<dirbaio[m]>
what did you benchmark
<atesterlol[m]>
JamesMunns[m]: tho i did see `take`
<atesterlol[m]>
but im not sure on the performance on it
<atesterlol[m]>
dirbaio[m]: the program
<atesterlol[m]>
used time command
<dirbaio[m]>
:|
<dirbaio[m]>
but you benchmarked fd-to-fd copy
<dirbaio[m]>
* you benchmarked someting that does fd-to-fd copy
<dirbaio[m]>
it's gotta be that
<dirbaio[m]>
the moment you add a custom Read wrapper it's not a fd-to-fd copy anymore
<atesterlol[m]>
dirbaio[m]: tho there is `sendfile`?
<atesterlol[m]>
so what is special about copy?
<atesterlol[m]>
oh i know why i got this implementation because it was fd-to-fd as you said
<atesterlol[m]>
s/implementation/result/
<atesterlol[m]>
but my reader is my own implemenation of Read
<atesterlol[m]>
so yes, but it still doesn't solve my original question tho
<dirbaio[m]>
rust's stdlib is using specialization (a magic unstable Rust feature that can't be used from outside the stdlib yet) to mark some Read/Write types as "this corresponds to a plain FD from the kernel"
<dirbaio[m]>
typically files and sockets
<dirbaio[m]>
so io::copy uses a fast path if BOTH the source and destination are FDs
<dirbaio[m]>
if not, it uses a plain old "read, write, repeat" loop
<atesterlol[m]>
dirbaio[m]: i dont see where it cares about it
<JamesMunns[m]>
dirbaio[m]: now THATs a doc comment
<atesterlol[m]>
dirbaio[m]: well what does properties will return?
<atesterlol[m]>
it extracts hints/metadata, which i guess part of the hints is that there is a socket inside...
<JamesMunns[m]>
this is probably not the road you want to go down, btw, dirbaio was just telling you why it was working like that
<atesterlol[m]>
anyway im not pretty sure how thats relevant since there is a performance improvment
<atesterlol[m]>
JamesMunns[m]: the comment above isn't intended to you
<atesterlol[m]>
JamesMunns[m]: btw he didn't explain why there is a performance improvement, i think he more was trying to say there isn't a performance improvement
<dirbaio[m]>
i've said it like 3 times
<dirbaio[m]>
there is a perf improvement ONLY if src and dst are BOTH files or sockets
<dirbaio[m]>
which is not your case, src will be custom decrypting adapter.
<dirbaio[m]>
so there won't be a perf improvement in your case
<dirbaio[m]>
even if there was in your benchmark
<dirbaio[m]>
because you benchmarked the wrong thing
<atesterlol[m]>
how so
<atesterlol[m]>
ok
<atesterlol[m]>
here is the benchmark
<atesterlol[m]>
without copy: `1.61s user 0.04s system 80% cpu 2.067 total`
<atesterlol[m]>
with copy: `0.39s user 0.05s system 58% cpu 0.752 total`
<JamesMunns[m]>
for what its worth, this room is usually for bare-metal or RTOS devices, and not linux
<JamesMunns[m]>
you might have better luck in the official discord or zulip, if this is something you are doing on Linux.
<atesterlol[m]>
JamesMunns[m]: oh. what happened to the previous one?
<JamesMunns[m]>
atesterlol[m]: previous what?
<atesterlol[m]>
JamesMunns[m]: the previous channel
<atesterlol[m]>
it has a crab logo
<atesterlol[m]>
* it had a crab logo
wyager[m] has joined #rust-embedded
<wyager[m]>
atesterlol[m]: Did you post the actual code for your benchmark anywhere?
<atesterlol[m]>
wyager[m]: i used `time`
<JamesMunns[m]>
atesterlol[m]: Do you mean https://matrix.to/#/#rust:matrix.org ?
<JamesMunns[m]>
JamesMunns[m]: this is the `rust-embedded` room, for embedded systems.
<atesterlol[m]>
JamesMunns[m]: oh yes
<atesterlol[m]>
i searched it in the channel list but couldn't find it, thought they changed the name for rust embedded
<JamesMunns[m]>
#rust:matrix.org might be a direct link in your client
<atesterlol[m]>
yep, thanks
<atesterlol[m]>
wyager[m]: anyway no
NickStevens[m] has joined #rust-embedded
<NickStevens[m]>
<JamesMunns[m]> "for what its worth, this room is..." <- There are definitely people here from the embedded Linux side of things too (like me), but agree most of the questions are coming from the bare-metal or RTOS side. I just don't want to scare off questions about things like meta-rust-bin, spidev, i2cdev, etc that are Linux hardware based.
<dirbaio[m]>
see? the perf advantage of std::io::copy goes away once you have a custom Read wrapper
<NickStevens[m]>
And atesterlol's question seems unrelated to hardware to me
bguruprasath5[m] has joined #rust-embedded
<bguruprasath5[m]>
Hello all, I’m using embassy on nrf52840 with embassy boot and softdevice for one of my projects. So far everything works perfectly. but some time randomly getting restart while performing operations when connected to Ble. is there any way to find out where and what is causing the restart. Or is there any logger we can use to find out the issue.
<atesterlol[m]>
<dirbaio[m]> "see? the perf advantage of std..." <- yep. you're right, but i still don't understand why it happens on my end like that