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

kn: checksum bindings #121

Merged
merged 10 commits into from
Dec 9, 2024
Merged

kn: checksum bindings #121

merged 10 commits into from
Dec 9, 2024

Conversation

lauzadis
Copy link
Member

@lauzadis lauzadis commented Nov 18, 2024

Description of changes:

  • Add MD5 implementation
  • Add WithCrt mixin class used to ensure CRT.initRuntime { } is called
    • Trying to use these CRT hash functions from smithy-kotlin would result in errors because CRT was not properly initialized
  • Fix an IndexOutOfBounds bug caused by passing empty inputs to hash functions

By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.

@lauzadis lauzadis marked this pull request as ready for review November 18, 2024 20:24
@lauzadis lauzadis requested a review from a team as a code owner November 18, 2024 20:24
Comment on lines +7 to +14
/**
* A mixin class used to ensure CRT is initialized before the class is invoked
*/
public open class WithCrt {
init {
CRT.initRuntime { }
}
}
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Question: I'm concerned with this approach for two reasons:

  1. Kotlin doesn't support true mixin classes so this pattern prevents inheritors from using any other superclass. Given that this functionality isn't truly polymorphic it seems prudent to leave the option open.
  2. This initializes the CRT runtime at object instantiation rather than when CRT functionality is actually necessary. If some code just instantiates a new Crc32 but never uses any methods on it, we'll've wasted cycles unnecessarily.

Could we move the initialization closer to the site of use?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Could we move the initialization closer to the site of use?

Sure, we'll just have to take care to initialize CRT everywhere we use it, which we currently don't do.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If some code just instantiates a new Crc32 but never uses any methods on it, we'll've wasted cycles unnecessarily.

This is true but in practice CRT is only initialized once, subsequent calls to CRT.initRuntime { } are no-ops. I'm assuming users of aws-sdk-kotlin Kotlin/Native will need to initialize CRT at some point

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We spoke offline and agreed to continue this approach for now. Ideally we would create a singleton object CrtLib and use cinterop to generate extensions for it (like CrtLib.aws_checksums_crc32(...)). This CrtLib object would ensure CRT.initRuntime { ... } is called before invoking the actual C function.

Comment on lines +27 to +30
if (input.isEmpty() || length == 0) {
return
}

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Question: Why is this necessary? What breaks if we just pass an empty blob or a 0 length down to CRT?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The request would never make it to CRT, the following code snippet fails with an ArrayIndexOutOfBoundsException exception:

        val offsetInput = input.usePinned {
            it.addressOf(offset)
        }

@lauzadis lauzadis merged commit 375b817 into kn-main Dec 9, 2024
13 of 16 checks passed
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

Successfully merging this pull request may close these issues.

2 participants