IMapIterator stuck?

Open
#324 0 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Assessment

Difficulty
3/5
Estimated time
1-2 days
Newbie friendliness
25/100
Issue type
Bug
Clarity
Needs clarification
Activity status
Stale
Tech stack
python
Domain
backend

Research direction

Start in billiard/pool.py around line 1957 and trace IMapIterator.next(), including the condition wait and lost_worker_timeout handling. Compare the behavior with the related Celery issue 4185; done means establishing whether the iterator can remain blocked and identifying the relevant behavior to report or correct.

Written by the indexing model from the issue text.

Description

I review billiard/pool.py line 1957, and I found:

self._cond = threading.Condition(threading.Lock())
......
self._lost_worker_timeout = lost_worker_timeout
......
def next(self, timeout=None):
    with self._cond:
            ......
            self._cond.wait(timeout)
            ......

self._cond.wait not set timeout. Is it stuck in this place ?

maybe related https://github.com/celery/celery/issues/4185

Dominant language
Python
Stars
436
Forks
273
Avg merge
4d 19h
Merged PRs (30d)
5

Getting set up

This project ships no dev container, Dockerfile or contributing guide, so setting up is up to you: start from its README, and see our first-contribution guide for the general steps.

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from celery/billiard

All issues in celery/billiard

Similar issues

More Python issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.