A number of js-ctypes integer types cannot be passed between threads. We need to implement (de)serialization of these types.

Comment on attachment 649599 [details] [diff] [review] Communicating numbers Review of attachment 649599 [details] [diff] [review]: ----------------------------------------------------------------- ::: toolkit/components/osfile/osfile_shared_allthreads.jsm @@ +490,5 @@ > + IntType.prototype.toMsg = function toMsg(value) { > + if (typeof value == "number") { > + return value; > + } > + return this.project(value); This is just trying to parse non-number things to numbers, correct? Or will it do interesting things with Int64 values and the like?

Comment on attachment 649599 [details] [diff] [review] Communicating numbers Review of attachment 649599 [details] [diff] [review]: ----------------------------------------------------------------- Clearing r? just to make my queue tidy. Feel free to flip it back on tomorrow--and get the blocking patches for this one checked in!

(In reply to Nathan Froyd (:froydnj) from comment #2) > Comment on attachment 649599 [details] [diff] [review] > Communicating numbers > > Review of attachment 649599 [details] [diff] [review]: > ----------------------------------------------------------------- > > ::: toolkit/components/osfile/osfile_shared_allthreads.jsm > @@ +490,5 @@ > > + IntType.prototype.toMsg = function toMsg(value) { > > + if (typeof value == "number") { > > + return value; > > + } > > + return this.project(value); > > This is just trying to parse non-number things to numbers, correct? Or will > it do interesting things with Int64 values and the like? For the moment, the only "interesting" thing it will do with Int64/UInt64 is throw an error if they do not fit in a JavaScript number.

Which, I should add, is by design. Without this |toMsg|, any attempt to communicate a [U]Int64 between workers will raise a weird DOM error without a line number. I prefer having a clean error, and the possibility to extend this at some point, once need arises.

(In reply to David Rajchenbach Teller from comment #5) > Which, I should add, is by design. Without this |toMsg|, any attempt to > communicate a [U]Int64 between workers will raise a weird DOM error without > a line number. I prefer having a clean error, and the possibility to extend > this at some point, once need arises. I think that's a reasonable strategy, especially given that 64-bit integers are going to be uncommon.

Green on Try. https://tbpl.mozilla.org/?tree=Try&rev=f4c4e1566e9b https://hg.mozilla.org/integration/mozilla-inbound/rev/f9a8c6ac4f16 David, I'm pretty sure you're running most of your patches through Try these days (yay!). If it's not too much trouble, can you please post a link to your most recent run when requesting checkin? It'll save build resources and get your patches checked in faster. Myself and the other sheriffs are trying to clamp down on landing patches without Try results, so if I don't see them in a bug, I'm running the patch through Try myself before landing. Thanks!