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

Rewrite rust_builtin helpers in Rust #4812

Closed
brson opened this issue Feb 6, 2013 · 7 comments
Closed

Rewrite rust_builtin helpers in Rust #4812

brson opened this issue Feb 6, 2013 · 7 comments
Labels
A-runtime Area: std's runtime and "pre-main" init for handling backtraces, unwinds, stack overflows C-cleanup Category: PRs that clean code up or issues documenting cleanup. E-easy Call for participation: Easy difficulty. Experience needed to fix: Not much. Good first issue.

Comments

@brson
Copy link
Contributor

brson commented Feb 6, 2013

There are a bunch of little one-off functions in rustrt that don't need to be. Some of these are using the exchange heap, blocking the completion of moving the exchange heap to Rust.

@olsonjeffery
Copy link
Contributor

Ok, so I've got a tentative list of c++ functions that I need to rewrite in rust to resolve this issue. I just want to make sure I've got my approach worked out correctly:

  • the c++ in src/rt that uses kernel->malloc() need to be rewritten in rust within core.
  • Within those codefiles in core, we will be using the private::exchange_alloc functions where we would use kernel->malloc() previously, otherwise keep the logic the same.

Is that correct?

NOTE: this implies moving std::uv_ll into core (rust_uv.cpp does some mallocs). Or should core export an API to do direct mallocs/frees to the exchange heap?

@olsonjeffery
Copy link
Contributor

also: wasn't sure if private::exchange_alloc is the right place for me to call? Don't know if that module is just germaine to the underlying c++ impl or if that's the interface behind which you'll finish the exchange heap in rust to resolve #4813. If I should be using somewhere else, please do tell.

@brson
Copy link
Contributor Author

brson commented Feb 9, 2013

@olsonjeffery that sounds about right. if you need to access the allocator directly then private::exchange_alloc is what to use. Please don't move uv into core yet, as that's not something I want to do lightly - std can get at the exchange allocator via core::rt::rt_exchange_malloc, or my making private::exchange_alloc public.

@olsonjeffery
Copy link
Contributor

OK cool. I have no problem using whatever is the public API in all
instances. Thanks for answering my questions.
On Feb 8, 2013 5:15 PM, "Brian Anderson" notifications@github.com wrote:

@olsonjeffery https://github.com/olsonjeffery that sounds about right.
if you need to access the allocator directly then private::exchange_allocis what to use. Please don't move uv into core yet, as that's not something
I want to do lightly - std can get at the exchange allocator via
core::rt::rt_exchange_malloc, or my making private::exchange_alloc public.


Reply to this email directly or view it on GitHubhttps://github.com//issues/4812#issuecomment-13323480..

@thestinger
Copy link
Contributor

We're closer to accomplishing this, but there's still a lot of stuff to be rewritten in Rust.

@huonw
Copy link
Member

huonw commented Sep 30, 2013

Triage: we're getting there, approximately half of the remaining contents of rust_builtin.cpp is time stuff (which would probably be relatively easy to transliterate into Rust + some FFI), and 15-20% are global mutexes (blocked on #9105).

@pnkfelix
Copy link
Member

@alexcrichton says while we still have rust_builtin.cpp, it is tiny and this does not matter as much.

Closing.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-runtime Area: std's runtime and "pre-main" init for handling backtraces, unwinds, stack overflows C-cleanup Category: PRs that clean code up or issues documenting cleanup. E-easy Call for participation: Easy difficulty. Experience needed to fix: Not much. Good first issue.
Projects
None yet
Development

No branches or pull requests

5 participants