The libfactory interface needs a C-level mutex
Nobody has claimed this yet.
- Dominant language
- Macaulay2
- Stars
- 435
- Forks
- 297
- Avg merge
- 4d 20h
- Merged PRs (30d)
- 11
Description
This issue was triaged from [`bugs/dan/0-add-mutex-for-factory`](https://github.com/Macaulay2/M2/blob/388c1ff0ce30d83751dea7bc7eac77fdc1305dd7/bugs/dan/0-add-mutex-for-factory), one of the 857 files removed from the pre-GitHub `bugs/` tree by [`d2c8d27826`](https://github.com/Macaulay2/M2/commit/d2c8d27826) and catalogued in [#36](https://github.com/Macaulay2/M2/issues/36). **The commentary below was written by Claude (Claude Opus 5, via Claude Code)**, not by @d-torrance, whose account posted it -- please weigh it accordingly.
### The original file, verbatim
```text
the libfactory interface is not thread safe.
This needs a C level mutex around it too.
```
### Where it stands today
Still true. There is no C-level lock around the libfactory interface, and the workaround is visible
in package code rather than in the interface: `ThreadedGB.m2:33` steers around factory instead of
serializing access to it.
### Why a mutex rather than a fix in factory
libfactory keeps global state — the current coefficient ring and the algebraic element used for
extension arithmetic among it, which `e/interface/factory.cpp` sets up per call — so two threads in
factory at once corrupt each other's setup rather than merely racing on a counter. Guarding the
interface is the only thing M2 can do from its side.
### Where this sits
This is one specific instance under **#175**, the umbrella thread-safety issue, alongside **#3675**,
**#3895** and **#3927**. It is worth keeping separate because the remedy is local and well
understood, where the umbrella is not.
Adjacent: #4583 concerns what factory is *told* about an extension, and would be touching the same
setup code.
`open` · disposition `issue` · source of truth: [`bug-triage/catalog.tsv`](https://github.com/d-torrance/M2/blob/bug-triage/bug-triage/catalog.tsv)
Contributor guide
No contributing guide indexed for this repository
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start by reading e/interface/factory.cpp and the workaround at ThreadedGB.m2:33, then trace how factory sets up its global state for extension arithmetic. Confirm the relevant concurrent-call behavior and identify the project’s existing factory or thread-safety checks; done means the libfactory interface no longer allows concurrent calls to corrupt that setup.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- cpp
- Domain
- backend-api-design
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Quiet
- Clarity
- Mostly clear
- Newbie friendliness
- 48/100