Loadingone moment…
Sign in to run and submit your work
Reading is open to everyone. Running code and saving drafts need an account so your work is yours and comes back on your next visit.
or
CODE WORKSPACE
"Would you use threads or processes?" is a standard interview question, and the standard answer — I/O-bound means threads, CPU-bound means processes — is half of one. The other half is how many tasks there are and what a worker costs in memory.
Write choose_model(workloads, limits). It returns one recommendation per workload, with the reason attached. This is a planning exercise: nothing here starts a thread, because the sandbox cannot.
Function to write
choose_model(workloads: list[dict], limits: dict) -> list[dict]A list of recommendations, one per workload, each carrying the model and the reason.
How to approach it
Find the workload where the textbook answer does not fit in memory.
Sample cases
+ 2 held back until you submit
five workloads, five verdicts
Every branch at once, including the single task and the CPU-bound job too fat for processes.
Input
Argument 1
| name | tasks | io_ms | cpu_ms | per_task_mb |
|---|---|---|---|---|
| fetch | 500 | 200 | 5 | 2 |
| parse | 40 | 5 | 300 | 128 |
| single | 1 | 100 | 1 | 1 |
| small-io | 10 | 50 | 5 | 4 |
| fat-parse | 10 | 1 | 500 | 900 |
Argument 2
{
'max_workers': 8,
'memory_budget_mb': 1024
}Returns
| name | model | reason |
|---|---|---|
| fetch | asyncio | more waiting tasks than threads are worth |
| parse | processes | CPU-bound work needs separate interpreters |
| single | sequential | one task cannot be made parallel |
| small-io | threads | I/O-bound work releases the GIL while it waits |
| fat-parse | sequential | processes would not fit in the memory budget |
a tight memory budget
The same workloads on a smaller machine: parse can no longer afford processes either.
Input
Argument 1
| name | tasks | io_ms | cpu_ms | per_task_mb |
|---|---|---|---|---|
| fetch | 500 | 200 | 5 | 2 |
| parse | 40 | 5 | 300 | 128 |
| single | 1 | 100 | 1 | 1 |
| small-io | 10 | 50 | 5 | 4 |
| fat-parse | 10 | 1 | 500 | 900 |
Argument 2
{
'max_workers': 8,
'memory_budget_mb': 200
}Returns
| name | model | reason |
|---|---|---|
| fetch | asyncio | more waiting tasks than threads are worth |
| parse | sequential | processes would not fit in the memory budget |
| single | sequential | one task cannot be made parallel |
| small-io | threads | I/O-bound work releases the GIL while it waits |
| fat-parse | sequential | processes would not fit in the memory budget |
no workloads
Nothing to recommend returns an empty list rather than a default verdict.
Input
Argument 1
[] (empty list)
Argument 2
{
'max_workers': 8,
'memory_budget_mb': 1024
}Returns
[] (empty list)
Constraints
{'name': ..., 'model': ..., 'reason': ...} per workload, in order.sequential — concurrency has a cost and nothing to overlap.cpu_ms strictly greater than io_ms is CPU-bound. A tie is not.processes — but a process copies the interpreter, so if memory_budget_mb // per_task_mb is under 2, the answer is sequential with the budget as the reason.max_workers * 4 tasks is asyncio; otherwise it is threads.max_workers defaults to 8 and memory_budget_mb to 1024 when the limits do not say.Worked example
fat-parse is unambiguously CPU-bound — 500ms of CPU against 1ms of I/O — so the textbook answer is processes. Each task needs 900MB and the budget is 1024MB.
One worker fits. One worker is not parallelism, so the honest recommendation is sequential, and the reason names the budget rather than the workload. That is the half of this question the CPU/IO ratio cannot answer, and it is the half an interviewer is actually listening for.
What this tests
That choosing a concurrency model is a decision with several inputs rather than a rule with one, and that a recommendation without a reason is useless to the person who has to defend it later.
choose_model(workloads: list[dict], limits: dict) -> list[dict]Submit for review to find out what your query gets right, what it gets wrong, and how it compares with the best working query for this exercise.
This scenario runs a full workspace — editor, canvas and results side by side. It needs a laptop or desktop to be usable. Open this page on a bigger screen to start building.