Comments on: Farewell PRLock; I hardly knew thee

By: dbradley

dbradley — Fri, 01 Apr 2011 14:03:31 +0000

I very much agree, a try lock would be great and seems like a good time to add it given these changes.

By: cjones

cjones — Wed, 06 May 2009 05:40:25 +0000

There are no plans to extend the API at the moment, but we could add |Trylock()| pretty easily. NSPR already has it, but it’s private to NSPR. You can file a bug on it if you’d find it really useful.

> 1) have a useful install that can run outside of the environment of whoever runs them now

Sort of. The install is a little tedious, but it’s documented here:

https://developer.mozilla.org/En/Pork

However, there’s a “magic” new tool that hasn’t landed yet. It should happen soon. I’ll blog about it in the near future.

> 2) run on non-libxul (i.e. external) code?

Yup, nothing Mozilla-specific here.

By: Mook

Mook — Wed, 06 May 2009 05:09:31 +0000

There is no plans to expand the API beyond what NSPR provides, correct? (In particular, a trylock would be awesome, but isn’t exposed by NSPR.)

Do the magic rewriting tools 1) have a useful install that can run outside of the environment of whoever runs them now, and 2) run on non-libxul (i.e. external) code?

By: cjones

cjones — Tue, 05 May 2009 23:43:59 +0000

Hey, I said *proto*-non-failing, didn’t I? BTW, it’s not all that bad of an idea, especially for sync primitives.

By: Christian Biesinger

Christian Biesinger — Tue, 05 May 2009 22:15:34 +0000

> Their constructors use a proto-non-failing malloc, so your code will never see out-of-memory errors.

The patch looks like the way it doesn’t fail is by aborting:
+ mLock = PR_NewLock();
+ if (!mLock)
+ NS_RUNTIMEABORT(“Can’t allocate mozilla::Mutex”);

seems like a horrible idea to me, but whatever…