bholley/atomic_refcell 15

Threadsafe RefCell for Rust

bholley/maul 12

A Machine Learning approach to User-Agent parsing

annevk/html-cross-origin-objects 2

Defining Window and Location

bholley/letgo 2

Firefox add-on to add a delay to time-wasting websites

bholley/bit-vec 0

A Vec of Bits

bholley/gecko 0

A git-cinnabar mirror of mozilla-central. Branches welcome! Ping @mykmelez for access.

bholley/geckoview 0

GeckoView is a set of components for embedding Gecko in Android apps

Pull request review commentbholley/atomic_refcell

Add try_borrow[_mut] and tests

 impl<T: ?Sized> AtomicRefCell<T> {         }     } +    /// Attempts to immutably borrow the wrapped value, but instead of panicking+    /// on a failed borrow, returns `Err`.+    #[inline]+    pub fn try_borrow(&self) -> Result<AtomicRef<T>, BorrowError> {

Let's put this directly after borrow() (so that the order is borrow, try_borrow, borrow_mut, try_borrow_mut).

Ideally we'd also implement borrow in terms of try_borrow.


comment created time in 15 days

Pull request review commentbholley/atomic_refcell

Add try_borrow[_mut] and tests

 struct AtomicBorrowRef<'b> { }  impl<'b> AtomicBorrowRef<'b> {+    #[inline]+    fn try_new(borrow: &'b AtomicUsize) -> Option<Self> {+        let new = borrow.fetch_add(1, atomic::Ordering::Acquire) + 1;++        // If the new count has the high bit set, return `None`. We're guaranteed+        // that on drop from a mutable borrow, the immutable count will be properly+        // set back to zero.

This loses all the soundness considerations in that ::new() has, via do_panic(). I think we need to refactor do_panic so that it's usable in the try-scenario. Ideally then we'd drop AtomicBorrowRef::new() and only have AtomicBorrowRef::try_new(), which would be delegated to by AtomicRefCell::try_borrow(), which would be delegated to by AtomicRefCell::borrow(). Similar for the mut case.


comment created time in 15 days


pull request commentbholley/atomic_refcell

Add try_borrow[_mut] and tests

Thanks for the PR! I agree the project should be rustfmt-ed, but would like that to be separate from functional changes. I've pushed a commit to do that, please rebase this on top of master and then I'll look at it.


comment created time in 16 days

push eventbholley/atomic_refcell

Bobby Holley

commit sha 19c0f767af98509672522443a3441d4e5708bb49


view details

push time in 16 days

issue commentmozilla/standards-positions

Screen Wake Lock API

I'll also just note that I don't think recent changes at Mozilla are all that relevant to this issue. This wasn't on any team's roadmap in March [1], and Gecko resourcing hasn't changed dramatically since then either. So while I agree the Firefox team is unlikely to be working on this feature soon, that's because it remains a lower priority for us than other opportunities to advance the Web, and not because of any kind of organizational or strategic change.

We'd certainly consider taking a patch though!

[1] As @mconca correctly notes, "worth prototyping" describes our willingness to experiment with the feature in Firefox rather than any commitment to resourcing it (though I can see how Marcos' comment in May could be misunderstood to imply that resourcing for this particular API was imminent).


comment created time in a month

issue commentmozilla/standards-positions

content-visibility API

@victorporof Can you make a PR to close this out? Thanks!


comment created time in 3 months

pull request commentsurma/

Update Firefox API status

LGTM I think. Not entirely sure how the "consideration" status will be surfaced in the UI but I'm guessing it'll be fine. Thanks!


comment created time in 3 months