Drop old fragments that `towncrier` somehow missed
parent
909c996346
commit
a95b0dc05e
|
@ -1,28 +0,0 @@
|
|||
Add "infected ``asyncio`` mode; a sub-system to spawn and control
|
||||
``asyncio`` actors using ``trio``'s guest-mode.
|
||||
|
||||
This gets us the following very interesting functionality:
|
||||
|
||||
- ability to spawn an actor that has a process entry point of
|
||||
``asyncio.run()`` by passing ``infect_asyncio=True`` to
|
||||
``Portal.start_actor()`` (and friends).
|
||||
- the ``asyncio`` actor embeds ``trio`` using guest-mode and starts
|
||||
a main ``trio`` task which runs the ``tractor.Actor._async_main()``
|
||||
entry point engages all the normal ``tractor`` runtime IPC/messaging
|
||||
machinery; for all purposes the actor is now running normally on
|
||||
a ``trio.run()``.
|
||||
- the actor can now make one-to-one task spawning requests to the
|
||||
underlying ``asyncio`` event loop using either of:
|
||||
* ``to_asyncio.run_task()`` to spawn and run an ``asyncio`` task to
|
||||
completion and block until a return value is delivered.
|
||||
* ``async with to_asyncio.open_channel_from():`` which spawns a task
|
||||
and hands it a pair of "memory channels" to allow for bi-directional
|
||||
streaming between the now SC-linked ``trio`` and ``asyncio`` tasks.
|
||||
|
||||
The output from any call(s) to ``asyncio`` can be handled as normal in
|
||||
``trio``/``tractor`` task operation with the caveat of the overhead due
|
||||
to guest-mode use.
|
||||
|
||||
For more details see the `original PR
|
||||
<https://github.com/goodboy/tractor/pull/121>`_ and `issue
|
||||
<https://github.com/goodboy/tractor/issues/120>`_.
|
|
@ -1,6 +0,0 @@
|
|||
Fix keyboard interrupt handling in ``Portal.open_context()`` blocks.
|
||||
|
||||
Previously this not triggering cancellation of the remote task context
|
||||
and could result in hangs if a stream was also opened. This fix is to
|
||||
accept `BaseException` since it is likely any other top level exception
|
||||
other then kbi (even though not expected) should also get this result.
|
|
@ -1,9 +0,0 @@
|
|||
Add a custom 'CANCEL' log level and use through runtime.
|
||||
|
||||
In order to reduce log messages and also start toying with the idea of
|
||||
"application layer" oriented tracing, we added this new level just above
|
||||
'runtime' but just below 'info'. It is intended to be used solely for
|
||||
cancellation and teardown related messages. Included are some small
|
||||
overrides to the stdlib's ``logging.LoggerAdapter`` to passthrough the
|
||||
correct stack frame to show when one of the custom level methods is
|
||||
used.
|
|
@ -1,9 +0,0 @@
|
|||
Add a custom 'CANCEL' log level and use through runtime.
|
||||
|
||||
In order to reduce log messages and also start toying with the idea of
|
||||
"application layer" oriented tracing, we added this new level just above
|
||||
'runtime' but just below 'info'. It is intended to be used solely for
|
||||
cancellation and teardown related messages. Included are some small
|
||||
overrides to the stdlib's ``logging.LoggerAdapter`` to passthrough the
|
||||
correct stack frame to show when one of the custom level methods is
|
||||
used.
|
|
@ -1,9 +0,0 @@
|
|||
Add ``trionics.maybe_open_context()`` an actor-scoped async multi-task
|
||||
context manager resource caching API.
|
||||
|
||||
Adds an SC-safe cacheing async context manager api that only enters on
|
||||
the *first* task entry and only exits on the *last* task exit while in
|
||||
between delivering the same cached value per input key. Keys can be
|
||||
either an explicit ``key`` named arg provided by the user or a
|
||||
hashable ``kwargs`` dict (will be converted to a ``list[tuple]``) which
|
||||
is passed to the underlying manager function as input.
|
|
@ -1,8 +0,0 @@
|
|||
Fix ``Portal.run_in_actor()`` returns ``None`` result.
|
||||
|
||||
``None`` was being used as the cached result flag and obviously breaks
|
||||
on a ``None`` returned from the remote target task. This would cause an
|
||||
infinite hang if user code ever called ``Portal.result()`` *before* the
|
||||
nursery exit. The simple fix is to use the *return message* as the
|
||||
initial "no-result-received-yet" flag value and, once received, the
|
||||
return value is read from the message to avoid the cache logic error.
|
|
@ -1,12 +0,0 @@
|
|||
Fix graceful cancellation of daemon actors
|
||||
|
||||
Previously, his was a bug where if the soft wait on a sub-process (the
|
||||
``await .proc.wait()``) in the reaper task teardown was cancelled we
|
||||
would fail over to the hard reaping sequence (meant for culling off any
|
||||
potential zombies via system kill signals). The hard reap has a timeout
|
||||
of 3s (currently though in theory we could make it shorter?) before
|
||||
system signalling kicks in. This means that any daemon actor still
|
||||
running during nursery exit would get hard reaped (3s later) instead of
|
||||
cancelled via IPC message. Now we catch the ``trio.Cancelled``, call
|
||||
``Portal.cancel_actor()`` on the daemon and expect the child to
|
||||
self-terminate after the runtime cancels and shuts down the process.
|
|
@ -1,9 +0,0 @@
|
|||
Add a per actor ``debug_mode: bool`` control to our nursery.
|
||||
|
||||
This allows spawning actors via ``ActorNursery.start_actor()`` (and
|
||||
other dependent methods) with a ``debug_mode=True`` flag much like
|
||||
``tractor.open_nursery():`` such that per process crash handling
|
||||
can be toggled for cases where a user does not need/want all child actors
|
||||
to drop into the debugger on error. This is often useful when you have
|
||||
actor-tasks which are expected to error often (and be re-run) but want
|
||||
to specifically interact with some (problematic) child.
|
|
@ -1,12 +0,0 @@
|
|||
Repair inter-actor stream closure semantics to work correctly with
|
||||
``tractor.trionics.BroadcastReceiver`` task fan out usage.
|
||||
|
||||
A set of previously unknown bugs discovered in `257
|
||||
<https://github.com/goodboy/tractor/pull/257>`_ let graceful stream
|
||||
closure result in hanging consumer tasks that use the broadcast APIs.
|
||||
This adds better internal closure state tracking to the broadcast
|
||||
receiver and message stream APIs and in particular ensures that when an
|
||||
underlying stream/receive-channel (a broadcast receiver is receiving
|
||||
from) is closed, all consumer tasks waiting on that underlying channel
|
||||
are woken so they can receive the ``trio.EndOfChannel`` signal and
|
||||
promptly terminate.
|
Loading…
Reference in New Issue