declared ClaudeBot · Anthropic · not verified
The user agent is ClaudeBot (Anthropic), which identifies itself as an AI agent.
Signals: Known agent user agent
This classification is final for the session. The human pages are not served to agents.
{
"question": {
"slug": "bounded-worker-pool",
"title": "Bounded Worker Pool",
"difficulty": "hard",
"tags": [
"coding",
"technical",
"backend"
],
"is_free": true,
"locked": false,
"frequency": 0.8,
"last_reported_at": "2026-08-23T08:54:23.813715Z",
"url": "https://www.mokabla.com/en/c/instabug/bounded-worker-pool",
"agent": {
"page": "https://www.mokabla.com/agent/en/c/instabug/bounded-worker-pool",
"question": "https://www.mokabla.com/agent/_call/get_question?company=instabug&question=bounded-worker-pool"
},
"company": {
"slug": "instabug",
"name_en": "Instabug"
},
"body_md": "## Problem\nOur symbolication service receives a list of jobs (each one resolves the frames of a crash against a dSYM or mapping file) and must run them with **at most `limit` in flight at once**, return results in the original order, and stop scheduling new work as soon as any job fails while still letting the in-flight ones finish. Implement `runPool(tasks, limit)` without using a ready-made pool class. Each task is a function returning a value (or a promise in JavaScript). I will then ask what changes if `limit` should adapt to CPU load, and how you would write a test that *proves* the concurrency bound.\n\n## Examples\n**Example 1**\nInput: 6 tasks each sleeping 50 ms, `limit = 2`\nOutput: results `[r0..r5]` in order; total wall time roughly 150 ms (three waves of two); peak concurrency observed is exactly 2.\n\n**Example 2**\nInput: tasks `[ok, ok, throws, ok, ok]`, `limit = 2`\nOutput: the call rejects/raises with the error from task 2; tasks 3 and 4 may have started only if they were already in flight when task 2 failed, never afterwards.\n\n## Constraints\n- Do not use `Promise.all` on everything at once, `asyncio.Semaphore` as the *only* mechanism, or `ThreadPoolExecutor`\n- Results must be indexed by input position, not completion order\n- Must be unit-testable: expose a way to observe peak concurrency\n\n## What they look for\nA shared cursor over the task list, `limit` worker loops each pulling the next index, a cancellation flag checked before each pull, error propagation with the first error winning, and a clear explanation of why the cursor is safe (single-threaded event loop in Node vs. a lock in Ruby/Go/Python threads).",
"follow_ups_md": "- Make `limit` adjustable while the pool is running.\n- Add per-task timeouts without leaking the underlying work.\n- How do you test 'never more than limit concurrent' deterministically?"
},
"paid": false,
"access": "Question bodies are paid content: a person buys 30 days of access per company (200 EGP or 200 points) in the human app. Agents get titles, tags and difficulty; bodies only for free questions."
}
| action | input | permission | |
|---|---|---|---|
| get_question One question with its body. Bodies are paid content unless the question is free. | company: string, question: string | Allowed | call → |
| list_questions The questions reported at a company: titles, tags, difficulty, whether each is free or paid. | company: string, page: number? | Allowed | call → |
| buy_access Buy 30 days of access to a company. | company: string | Refused R1 This action is for people only | people: https://www.mokabla.com/en/pricing |
| post_comment Comment on a question. | question: string, text: string | Refused R1 This action is for people only | people: https://www.mokabla.com/en/companies |
Allowed actions answer in JSON. Add ?format=json or send Accept: application/json to get this whole page as data.