8000
Skip to content

Add fxvector->cpointer.#2478

Draft
samth wants to merge 2 commits intoracket:masterfrom
samth:fxvector-cpointer
Draft

Add fxvector->cpointer.#2478
samth wants to merge 2 commits intoracket:masterfrom
samth:fxvector-cpointer

Conversation

@samth
Copy link
Copy Markdown
Member
@samth samth commented Feb 14, 2019

Needs docs/tests still.

@samth samth marked this pull request as draft June 25, 2020 14:10
@racket-discourse-github-bot
Copy link
Copy Markdown
racket-discourse-github-bot commented Dec 2, 2024

This pull request has been mentioned on Racket Discourse. There might be relevant details there:

https://racket.discourse.group/t/fxvector-cpointer/3385/2

@Metaxal
Copy link
Copy Markdown
Contributor
Metaxal commented Dec 2, 2024

Any chance to see this merged soon? That would be quite useful to me.

@mflatt
Copy link
Copy Markdown
Member
mflatt commented Dec 2, 2024

An fxvector has a different representation strategy than an flvector. The change here would expose a pointer whose elements are not ints that fit in the fixnum range, but Scheme encodings of those ints, which will vary by platform and backend (CS vs. BC). That is, the value in each intptr_t-sized set of bytes in the referenced memory would need to be arithmetic-shifted right by 1 to 3 bits to get an integer value, depending. Is that what you expected @Metaxal?

@Metaxal
Copy link
Copy Markdown
Contributor
Metaxal commented Dec 2, 2024

Wouldn't _fixnum in (ptr-ref cptr _fixnum idx) handle the conversion from bytes to a scheme fixnum?

@Metaxal
Copy link
Copy Markdown
Contributor
Metaxal commented Dec 2, 2024

To be clearer, perhaps, I don't particularly care of the internal representation as bytes in memory, as long as I have access to converters for ptr-ref and ptr-set!, and that I can use memcpy directly on the memory segments.

(Though if zero'ed bytes don't correspond to the fixnum 0, that's a little annoying as I can't use memset to zero out a vector.)

It's not the end of the world for me if I can't get these, I'm pretty sure I can find a workaround if needed.

@mflatt
Copy link
Copy Markdown
Member
mflatt commented Dec 2, 2024

A _fixnum still corresponds to intptr_t on the foreign side, but _racket would perform the conversion. If that's useful, then ok. But I had imagined the goal was to get a pointer who content can make sense on the foreign side.

@Metaxal
Copy link
Copy Markdown
Contributor
Metaxal commented Dec 2, 2024

But I had imagined the goal was to get a pointer who content can make sense on the foreign side.

I don't have another side. I'm allocating shared memory via shm and mmap, so as to share flvectors and fxvectors between multiple racket instances. AFAIU, I can't convert the allocated memory directly to flvector and fxvector unfortunately, so I've been rewriting shm-flvector and shm-fxvector interfaces — though perhaps I took the wrong approach?

@Metaxal
Copy link
Copy Markdown
Contributor
Metaxal commented Dec 2, 2024

I've given this more thought and I understand why you hesitate to expose fxvector->cpointer. I can definitely work around this, so don't waste your time on this. Thanks for looking into it in any case.

@shhyou shhyou added the pr:forgotten No activity for six months: can't find a reviewer, no continued dev, stuck since no consensus label Sep 17, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

No reviews

Assignees

No one assigned

Labels

pr:forgotten No activity for six months: can't find a reviewer, no continued dev, stuck since no consensus

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

5 participants

@samth @racket-discourse-github-bot @Metaxal @mflatt @shhyou
0