Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Store a State# RealWorld in the ByteString #684

Open
DemiMarie opened this issue Jun 22, 2024 · 3 comments
Open

Store a State# RealWorld in the ByteString #684

DemiMarie opened this issue Jun 22, 2024 · 3 comments

Comments

@DemiMarie
Copy link

This allows passing the state thread used to initialize the ByteString’s pointer to the functions that access that pointer. As a result, deferForeignPtrAvailability can be removed, and most or all uses of accursedUnutterablePerformIO can be replaced with a safer function that takes a State# RealWorld argument.

@clyring
Copy link
Member

clyring commented Jun 26, 2024

I briefly considered this as an alternative to the current deferForeignPtrAvailability stuff in 2022. But:

  • It's a rather invasive change, requiring basically all code that reads the contents of ByteStrings unsafely using ByteString internals to be rewritten.
    • I think there is probably much more code out there that performs such unsafe reads than code that unsafely creates ByteStrings directly using the constructor.
  • The necessary function unsafeReadFromByteString :: ByteString -> (ForeignPtr Word8 -> Int -> IO a) -> a is not really any safer than accursedUnutterablePerformIO, although at least the conditions under which it is safe are probably more obvious to the uninitiated.
  • Another function unsafeReadFromByteStringIO :: ByteString -> (ForeignPtr Word8 -> Int -> IO a) -> IO a is needed to allow reading from more than one ByteString in a single IO state thread.

From my perspective, the most principled solution would be for base to provide both MutableForeignPtr and ImmutableForeignPtr types, and just store an ImmutableForeignPtr Word8 in each ByteString. Then, read operations don't need to pretend to do IO, and initializing a ByteString ultimately involves calling an unsafeFreezeMutableForeignPtr primitive at the right time.

But I don't know how to realistically get there from the current status quo.

@DemiMarie
Copy link
Author

Could ByteString provide the needed types itself?

@clyring
Copy link
Member

clyring commented Jul 6, 2024

Could ByteString provide the needed types itself?

There is some argument for doing so. After all, the only difference between a ByteString and an ImmutableForeignPtr Word8 is that the former stores the length of (the relevant part of) its buffer.

But the main obstacles are impact assessment and migration, rather than finding the best possible home for the relevant types.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants