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

libstd: add an RAII utility for sys_common::mutex::Mutex #51529

Merged
merged 1 commit into from
Jun 17, 2018

Conversation

nodakai
Copy link
Contributor

@nodakai nodakai commented Jun 13, 2018

It is indeed debatable whether or not we should introduce more sophistication like this to the lowest layer of a system library. In fact, Drop::drop() cannot be unsafe (IIRC there was a discussion on introducing an unsafe variant of Drop whose entire scope must be within unsafe)

@rust-highfive
Copy link
Collaborator

r? @withoutboats

(rust_highfive has picked a reviewer for you, use r? to override)

@rust-highfive rust-highfive added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Jun 13, 2018
Copy link
Contributor

@oli-obk oli-obk left a comment

Choose a reason for hiding this comment

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

What's the motivation for this change? I don't disapprove at all, I'm just curious!

@@ -20,6 +20,9 @@ pub struct Lazy<T> {
init: fn() -> Arc<T>,
}

// wish we had a "polymorphic constant" of type *mut Arc<T>...
Copy link
Contributor

Choose a reason for hiding this comment

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

You can create a generic const fn

let ret = (0..ARGC).map(|i| {
let cstr = CStr::from_ptr(*ARGV.offset(i) as *const libc::c_char);
OsStringExt::from_vec(cstr.to_bytes().to_vec())
}).collect();
LOCK.unlock();
return ret
Copy link
Contributor

Choose a reason for hiding this comment

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

The temporary ret can be removed now

@@ -427,7 +426,6 @@ pub fn env() -> Env {
iter: result.into_iter(),
_dont_send_or_sync_me: PhantomData,
};
ENV_LOCK.unlock();
return ret
Copy link
Contributor

Choose a reason for hiding this comment

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

The temporary ret can be removed now

let s = libc::getenv(k.as_ptr()) as *const libc::c_char;
let ret = if s.is_null() {
None
} else {
Some(OsStringExt::from_vec(CStr::from_ptr(s).to_bytes().to_vec()))
};
ENV_LOCK.unlock();
return Ok(ret)
Copy link
Contributor

Choose a reason for hiding this comment

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

The temporary ret can be removed now

let ret = cvt(libc::setenv(k.as_ptr(), v.as_ptr(), 1)).map(|_| ());
ENV_LOCK.unlock();
return ret
Copy link
Contributor

Choose a reason for hiding this comment

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

Here too

@@ -480,9 +476,8 @@ pub fn unsetenv(n: &OsStr) -> io::Result<()> {
let nbuf = CString::new(n.as_bytes())?;

unsafe {
ENV_LOCK.lock();
let _guard = ENV_LOCK.lock();
let ret = cvt(libc::unsetenv(nbuf.as_ptr())).map(|_| ());
Copy link
Contributor

Choose a reason for hiding this comment

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

and here

/// A simple RAII utility for the above Mutex without the poisoning semantics.
pub struct MutexGuard<'a>(&'a imp::Mutex);

impl<'a> Drop for MutexGuard<'a> {
Copy link
Contributor

Choose a reason for hiding this comment

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

I'm wondering whether a closure based approach would be better, since you are often creating a new scope for the lock guard anyway.

@nodakai
Copy link
Contributor Author

nodakai commented Jun 14, 2018

@oli-obk Well, just a refactoring? sys_common/remutex.rs is another internal mutex library with an elaborated implementation of an RAII guard.

I wasn't sure about the flexibility of a closure-based approach (it surely works for the existing rustc codebase.) And we'd need unsafe { } around unsafe fn with_locked<T, F: FnOnce() -> T>(f: F) after all...

I will remove unnecessary returns

@nodakai nodakai force-pushed the improve-sys_common-mutex branch from 3859cf7 to 9ab19bc Compare June 17, 2018 06:58
Signed-off-by: NODA, Kai <nodakai@gmail.com>
@nodakai nodakai force-pushed the improve-sys_common-mutex branch from 9ab19bc to b81da27 Compare June 17, 2018 07:39
@nodakai
Copy link
Contributor Author

nodakai commented Jun 17, 2018

@oli-obk Updated accordingly. Thanks for the comments!

@oli-obk
Copy link
Contributor

oli-obk commented Jun 17, 2018

@bors r+

@bors
Copy link
Contributor

bors commented Jun 17, 2018

📌 Commit b81da27 has been approved by oli-obk

@bors bors added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Jun 17, 2018
@bors
Copy link
Contributor

bors commented Jun 17, 2018

⌛ Testing commit b81da27 with merge 86a8f1a...

bors added a commit that referenced this pull request Jun 17, 2018
libstd: add an RAII utility for sys_common::mutex::Mutex

It is indeed debatable whether or not we should introduce more sophistication like this to the lowest layer of a system library. In fact, `Drop::drop()` cannot be `unsafe` (IIRC there was a discussion on introducing an unsafe variant of `Drop` whose entire scope must be within `unsafe`)
@bors
Copy link
Contributor

bors commented Jun 17, 2018

☀️ Test successful - status-appveyor, status-travis
Approved by: oli-obk
Pushing 86a8f1a to master...

@bors bors merged commit b81da27 into rust-lang:master Jun 17, 2018
@nodakai nodakai deleted the improve-sys_common-mutex branch June 18, 2018 04:05
@@ -423,12 +422,10 @@ pub fn env() -> Env {
}
environ = environ.offset(1);
}
let ret = Env {
return Env {
Copy link
Contributor

Choose a reason for hiding this comment

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

This return is unnecessary, right?

Copy link
Contributor Author

@nodakai nodakai Jun 22, 2018

Choose a reason for hiding this comment

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

Unfortunately the inner function definition fn parse() below confuses the rustc parser if we omit the return

https://play.rust-lang.org/?gist=c39c88d10b00029672798633965295b3&version=stable&mode=debug

Copy link
Contributor

Choose a reason for hiding this comment

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

Oh, I see. This is pretty weird - I'd have expected the inner function to precede the actual code of the function (or to be inlined, since it has just one caller).

Thanks for explaining.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants