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.

Sign up for GitHub

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

Jump to bottom

extend fmt! to handle f32 and f64 types #3809

Closed
erickt opened this issue Oct 18, 2012 · 1 comment
Closed

extend fmt! to handle f32 and f64 types #3809

erickt opened this issue Oct 18, 2012 · 1 comment

Comments

@erickt
Copy link
Contributor

erickt commented Oct 18, 2012

Right now we need to cast to floats in order to print them out.
@brson
Copy link
Contributor

brson commented Oct 22, 2012

Duplicate of #1653

@brson brson closed this as completed Oct 22, 2012
bors pushed a commit to rust-lang-ci/rust that referenced this issue May 15, 2021
@scampi @topecongiro
improve detection of URL inside a string that is being rewritten. (ru…
8073244 
…st-lang#3809)
RalfJung pushed a commit to RalfJung/rust that referenced this issue Aug 18, 2024
@bors
Auto merge of rust-lang#3809 - RalfJung:fd-refcell, r=oli-obk
83f1b38 
FD: remove big surrounding RefCell, simplify socketpair

A while ago, I added the big implicit RefCell for all file descriptions since it avoided interior mutability in `eventfd`. However, this requires us to hold the RefCell "lock" around the entire invocation of the `read`/`write` methods on an FD, which is not great. For instance, if an FD wants to update epoll notifications from inside its `read`/`write`, it is very crucial that the notification check does not end up accessing the FD itself. Such cycles, however, occur naturally:
- eventfd wants to update notifications for itself
- socketfd wants to update notifications on its "peer", which will in turn check *its* peer to see whether that buffer is empty -- and my peer's peer is myself.

This then also lets us simplify socketpair, which currently holds a weak reference to its peer *and* a weak reference to the peer's buffer -- that was previously needed precisely to avoid this issue.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@erickt @brson