On Thu, Jul 4, 2024 at 9:26 PM Heikki Linnakangas <hlinnaka@iki.fi> wrote:
> On 15/04/2024 04:20, Thomas Munro wrote:
> > I was grepping for iovec users and noticed that the shm_mq stuff
> > defines its own iovec struct. Is there any reason not to use the
> > standard one, now that we can? Will add to next commitfest.
>
> I think it's better to keep them separate. They serve a similar purpose,
> but they belong to completely separate APIs; I think "incidental
> deduplication" is the right term for that. shm_mq_iovec is only used by
> our shm queue implementation, while struct iovec is part of the POSIX
> API. We wouldn't want to leak IOV_MAX into how shm_mq_iovec is used, for
> example. Or as a thought experiment, if our shm_mq implementation needed
> an extra flag in the struct or something, we would be free to just add
> it. But if it we reused struct iovec, then we couldn't, or we'd need to
> create a new struct again.
Thanks for looking. I marked this "returned with feedback".
(For future parallel query work, I have a scheme where queues can
spill to disk instead of blocking, which unblocks a bunch of parallel
execution strategies that are currently impossible due to flow control
deadlock risk. Then the two APIs meet and it annoys me that they are
not the same, so maybe I'll talk about this again some day :-))