{
  "$type": "site.standard.document",
  "bskyPostRef": {
    "cid": "bafyreifjyfotjgzr647avojkezzcs5lfitucb7birwps2h4a5grhcyr43a",
    "uri": "at://did:plc:hqad6xwuzg7oqfmwylfkvqfm/app.bsky.feed.post/3miihtnk35h22"
  },
  "path": "/viewtopic.php?t=33281&p=271728#p271728",
  "publishedAt": "2026-04-02T05:00:38.000Z",
  "site": "http://forum.palemoon.org",
  "tags": [
    "https://gitlab.com/seamonkey-project/se ... .cpp#L1179",
    "bug #1431353",
    "bug #1350760",
    "bug #1379814"
  ],
  "textContent": "> SeaMonkey removed the limit in maxParseThreads in their own Mozilla fork: https://gitlab.com/seamonkey-project/se ... .cpp#L1179\n>\n> Blaming it points me to bug #1431353, which pretty much depends on a per-zone atom cache added by bug #1350760, and this solution to the dining philosophers deadlock (related to wasm) in HelperThreads by bug #1379814.\n\nGood research, Job!\n\nYeah, that was it... BZ 1350760. I _definitely_ saw that one referenced during the WebComponents migration on IRC ages ago. G4JC mentioned it and thought it would be good to pull it in, but the... umm, guy overseeing the whole WebComponents endeavor at the time kind of dismissed it (understandably) for being irrelevant to the core issue of WebComponents without encouraging him to open another issue for it. We were all so laser-focused on WebComponents, particularly Custom Elements and Shadow DOM. There were a lot of times we'd be hunting through Bugzilla and find a lot of slightly off-topic things that looked potentially good to pick up, and then drop them on the floor without ever filing another issue because it felt like there would be a lot of \"red tape\" so to speak, plus we were already doing so much work rushing to get WebComponents off the ground.\n\n* * *",
  "title": "Platform Development • Re: e10s support question",
  "updatedAt": "2026-04-02T05:00:38.000Z"
}