<tazjin>
qyliss: what type are you doing this for anyways?
<tazjin>
I was discussing this on work chat and the question of how the type can't be Clone came up if it's serialisable
<tazjin>
(as in, couldn't you copy the serialised bytes anyways to make a Clone?)
<qyliss>
tazjin: Types enclosing file descriptors
<qyliss>
or, to put it better, types that represent file descriptor ownership
<qyliss>
Because if you sent a file descriptor through a socket, you get another file descriptor on the other side, which is basically a cloned one
<qyliss>
e.g. in crosvm, EventFd isn't clone, but it does have a try_clone method (because dup(2) can fail)
<qyliss>
So, I'd say in general, types that aren't clone because cloning them can fail
<tazjin>
hm, so the serialisation path is via into/from RawFd?
<qyliss>
yeah
<qyliss>
Currently I have to send RawFds, because I don't own the descriptors on the sending side
<qyliss>
But that's annoying, because, e.g. EventFd implements MsgOnSocket via its internal RawFd, and it would be nice to get an EventFd out on the other side rather than having to construct one myself
<qyliss>
Especially because that requires an unsafe block every time, because constructiving EventFd from RawFd is unsafe in the general case because you might not own the fd
<qyliss>
Like, it's unsafe to make an EventFd from an arbitrary RawFd, but not to make one from something you just got from recvmsg(2)
<tazjin>
qyliss: hm wait a second
<tazjin>
MsgOnSocket::write_to_buffer takes a &self
<tazjin>
as just pointed out by someone on another chat
<tazjin>
shouldn't that just work if you implement the trait for T?
<tazjin>
i.e. deserialise to Self, pass in &self
<qyliss>
but then what do I put in my struct Message
<qyliss>
that derives MsgOnSocket
<qyliss>
I want a #[derive(MsgOnSocket)] struct Message { evt: BorrowedOrOwned<EventFd> }
<qyliss>
You're correct that if I was just sending single EventFds over the wire at a time, this wouldn't be an issue
<tazjin>
ah - and Message has other fields, too, presumably
<qyliss>
yeah
<qyliss>
my current one has 10 fields, of which seven are various types of file descriptor wrapped in, e.g. EventFd or UnixSeqpacket, and others are just data that gets serialized as you'd expect
<qyliss>
I think my solution will end up being splitting MsgOnSocket into seperate traits for serializing and deserializing
<tazjin>
probably sensible
cole-h has quit [Ping timeout: 255 seconds]
<MichaelRaskin>
qyliss: if you want to send such a type, it is a surprise to me that you can send borrowed even on its own (by I don't write Rust). Are channels mandatory-bidirectional?
<nicoo>
qyliss: Just wanted to let you know I haven't forgotten about Spectrum, I've just been sick all of 2020 so far >_>'