-
-
Notifications
You must be signed in to change notification settings - Fork 50
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Added the possibility of synchronous initialization #438
Conversation
Prior to this commit, you could only initialize a queue in an asynchronous function. Now it is possible in synchronous, but you need to pass the event loop (even empty\not running) to the constructor
@s0d3s The asyncio.Condition and Event in the Queue.init should also pass the self._loop. Otherwise, it will raise the following Error
|
Calling |
I can imagine an alternative design with postponed initialization. The first case is trivial: all structures are initialized as now but later in time. The second case is more complex: sync init could instantiate only Double-checked locking should be used b calling both sync and async inits to prevent racing. The proposal is viable but not trivial. |
It's not such a challenge, but it's accepted😉 Wait for the news soon. |
… the Queue. The behavior of all functions after initialization has not changed. Also the duplicated code from `_notify_(a)sync_not_(empty/full)` was moved to a separate `_notify_(a)sync_condition` function. As a result, the bug that `_notify_sync_not_empty` did not add a handler to `_pending` was also fixed. Prior to full initialization, some `Queue` attributes are replaced with dummies. It is worth noting that `async_q` is replaced with an instance of the `PreInitDummyAsyncQueue` class before `Queue` is fully initialized. Although after full initialization, `Queue.async_q` is replaced by the desired object, it is worth remembering that the reference to `PreInitDummyAsyncQueue` obj could remain with the user. However, this is not a problem since after initialization, the dummy starts working as a proxy.
…es (in various combinations)
I set myself the main task - to introduce new functionality while not changing the behavior of the existing one. The decisions made to achieve this may seem controversial (for a short introduction, see the commit comment). Nevertheless, all tasks were completed. Now the following is possible:
import janus
if __name__ == '__main__':
items_count = 10
queue = janus.Queue(maxsize=items_count, init_async_part=False)
for i in range(items_count):
queue.sync_q.put(i)
while not queue.sync_q.empty():
print(queue.sync_q.get(), end=" ")
P.S. @asvetlov I took note of your comments, but found no use for them. |
Superseded by #710 |
What do these changes do?
Prior to this commit, you could only initialize a queue in an asynchronous function. Now it is possible in synchronous, but you need to pass the event loop (even empty\not running) to the constructor
Just a new way to init janus. But gives more ways to handle exceptions and code manage.
(Minimum code to understand the changes)
Are there changes in behavior for the user?
There are no behavior changes for users.
Checklist
CHANGES
folder<issue_id>.<type>
(e.g.588.bugfix
)issue_id
change it to the pr id after creating the PR.feature
: Signifying a new feature..bugfix
: Signifying a bug fix..doc
: Signifying a documentation improvement..removal
: Signifying a deprecation or removal of public API..misc
: A ticket has been closed, but it is not of interest to users.Fix issue with non-ascii contents in doctest text files.