Wrappers for pread & pwrite.

[zenhack]

Like the title says, there don't seem to be any wrappers for pread & pwrite -- these would be useful.

[portnov]

Hello.
A note: there is a module named System.Posix.IO.ByteString in the package unix-bytestring; that module offers very similar functionality to the module named System.Posix.IO.ByteString in the unix package, but that one provides fdPread, fdPWrite.

The coincidence of module names is too bad, though...

[zenhack]

Good to know, thanks for the pointer.

[hs-viktor]

If you really want to this moved into unix, please open a PR, but if unix-bytestring suffices, we can close this...

[zenhack]

I'm unlikely to open a PR; at a certain point I got frustrated with the existing set of packages and wrote https://hackage.haskell.org/package/unix-simple. Feel free to close.

[hasufell]

Yeah, I think 4 years isn't a reasonable time frame to respond to feature requests.

[zenhack]

To crystal be clear, I don't think I am owed a response at all, much less in a specific time frame. The package I wrote was as much addressing general design issues I saw as it was dealing with particular missing functions; my message yesterday was merely meant to communicate that I'd moved on, though looking back I see that without tone of voice to aid it could be interpreted as somewhat passive-agressive, and if it was taken that way I apologize.

[hasufell]

Well, my point is that we possibly lost a contributor, because we didn't manage to respond in time and provide both an opinion and guidance about a possible implementation. I think that needs to improve for boot libraries.

[Bodigrim]

@hasufell it's not Viktor's fault that previous maintainers were unresponsive for years.

[hasufell]

@hasufell it's not Viktor's fault that previous maintainers were unresponsive for years.

I wasn't trying to imply that. Just saying that from a contributors point of view this is depressing and boot libraries should do better.

[vdukhovni]

I must sheepishly admit to also have been cycle-starved recently, and would ideally have piped up somewhat sooner. Mea culpa. That said, my intent is to make amends shortly. In light of that, let's return to this PR. Is there still a desire to see pwrite and pread implemented?

My FreeBSD pwrite(2) manpage states:

STANDARDS
     The write() system call is expected to conform to IEEE Std 1003.1-1990
     (“POSIX.1”).  The writev() and pwrite() system calls are expected to
     conform to X/Open Portability Guide Issue 4, Version 2 (“XPG4.2”).

So pwrite is POSIX for a sufficiently recent version of POSIX. So perhaps the case for inclusion is reasonable?

[zenhack]

I think it would certainly still make sense, at least for pwrite -- though as I noted I have sortof moved on for my own projects. Thinking about it I'm not sure how pread should actually work, since it normally takes a series of buffers to read into, so a high level translation that returned [ByteString] or such wouldn't really make sense, since there's no clear way to know how to size the buffers. It only really makes sense if the caller is providing the buffers. Quoting Viktor Dukhovni (2022-04-15 01:05:30)

…

I must sheepishly admit to also have been cycle-starved recently, and would ideally have piped up somewhat sooner. Mea culpa. That said, my intent is to make amends shortly. In light of that, let's return to this PR. Is there still a desire to see pwrite and pread implemented? My FreeBSD pwrite(2) manpage states: STANDARDS The write() system call is expected to conform to IEEE Std 1003.1-1990 (�POSIX.1�). The writev() and pwrite() system calls are expected to conform to X/Open Portability Guide Issue� 4, Version� 2 (�XPG4.2�). So pwrite is POSIX for a sufficiently recent version of POSIX. So perhaps the case for inclusion is reasonable? -- Reply to this email directly, [1]view it on GitHub, or [2]unsubscribe. You are receiving this because you authored the thread. Message ID: ***@***.***> Verweise 1. #105 (comment) 2. https://github.com/notifications/unsubscribe-auth/AAGXYPWPBCMRAZZIU3EVCS3VFD2JVANCNFSM4ELIILVQ

[hs-viktor]

Thinking about it I'm not sure how pread should actually work, since it normally takes a series of buffers to read into, so a high level translation that returned [ByteString] or such wouldn't really make sense

Perhaps you're thinking of readv(2) rather than pread which takes a single buffer, although there are of course also pwritev and preadv which operate in the way you note. And naturally both readv and preadv with multiple scatter/gather buffers don't make sense unless the buffers are pre-allocated and mutable, thus Ptr Word8 rather than ByteString.

Some of this was discussed a while back in the context of the network package and recvmsg, in which I participated, but no longer recall the details. I'll go back and look what transpired in the end.

[zenhack]

Quoting Viktor Dukhovni (2022-04-15 15:46:51)

although there are of course also pwritev and preadv

Ah, you're right I was thinking of preadv; sorry, not paying enough attention apparently. pread should be straightforward.

[hasufell]

@hs-viktor

I'll go back and look what transpired in the end

Do we have more insights now?

[vdukhovni]

Yes, in network the recvMsg function returns a single ByteString result, rather than (pointless) an array of ByteStrings. If the application were in the business of reusing a mutable preallocated scatter/gather vector for multiple reads, then it would make sense to take an array of (Ptr8 Word8, CSize) buffers, but this is rather non-idiomatic in Haskell. So the natural API for preadv would be the same as for pread, making the former unnecessary.

With pwritev we could of course write out an array of ByteStrings. If there is still interest in this feature, I can at least review...