| Revision | d2699eb160b915c917845d489270d17c2ad7f8e2 (tree) |
|---|---|
| Time | 2020-03-22 07:11:46 |
| Author | Albert Mietus < albert AT mietus DOT nl > |
| Commiter | Albert Mietus < albert AT mietus DOT nl > |
PubSub: Add some notes (eg on thread)
SoftwareCompetence/DesignWorkShops/PubSub/concept/API.rst (diff) SoftwareCompetence/DesignWorkShops/PubSub/concept/Use.rst (diff)| @@ -6,9 +6,7 @@ | ||
| 6 | 6 | The Pub/Sub API |
| 7 | 7 | =============== |
| 8 | 8 | |
| 9 | -As typical with *Design Patterns* there are many ways to implement it. Here we focus on the “Topic” approach. It | |
| 10 | -decouples modules by defining a generic interface, and act as a kind of “man-in-the-middle”. | |
| 11 | - | |
| 9 | +This is the API (and implementation) of a simple :class:`~pubsub.Topic` class; as used in :ref:`PubSub_Use`. | |
| 12 | 10 | Topic |
| 13 | 11 | ===== |
| 14 | 12 |
| @@ -58,3 +58,31 @@ | ||
| 58 | 58 | * :class:`pubsub.AbstractType.Publisher` |
| 59 | 59 | * :class:`pubsub.AbstractType.Subscriber` |
| 60 | 60 | * :ref:`CallBack Signature <PubSub_callback_signature>` |
| 61 | + | |
| 62 | + | |
| 63 | +Threads | |
| 64 | +======= | |
| 65 | + | |
| 66 | +You might be wondering about threads: are they needed, essential of even possible? | |
| 67 | +|BR| | |
| 68 | +The simple answer is: It’s an “(I) don’t care!” | |
| 69 | + | |
| 70 | +It is also depending on the implementation. The shown implementation does not need, nor use threads. Remember, the | |
| 71 | +(main) goal is **decouple** (modules) and make it a *scalable* solution. Effectively, the ``Publisher`` is calling the | |
| 72 | +`callback` of the ``Subscribers`` (in a loop); like in a conventional, *direct call* solution. | |
| 73 | +|BR| | |
| 74 | +That `callback` will run in the same thread as the ``Publisher``, though it can schedule some work on another thread. By | |
| 75 | +example, with a :ref:`TPE`. | |
| 76 | + | |
| 77 | +Notwithstanding, it might be beneficial to include a :ref:`TPE` (or any other concurrency concept) within the | |
| 78 | +implementation of ``Topic``. Then, the runtime of ``t.publish()`` can controlled; even become *RealTime*. | |
| 79 | + | |
| 80 | +Questionnaire | |
| 81 | +------------- | |
| 82 | + | |
| 83 | +#. Why can the runtime of ``t.publish`` be unbound? | |
| 84 | + |BR| | |
| 85 | + Give an example. (in this implementation). | |
| 86 | +#. Why isn’t a theading implementation **not** always better? | |
| 87 | + |BR| | |
| 88 | + Give an example of on when ``t.publish()`` with threads is slower a the current one |
Fork