# More Threads!
[](https://pypi.org/project/mo-threads/)
[](https://github.com/klahnakoski/mo-threads/actions/workflows/build.yml)
[](https://coveralls.io/github/klahnakoski/mo-threads?branch=dev)
[](https://pepy.tech/project/mo-threads)
## Module `threads`
The main benefits over Python's threading library is:
1. **Shutdown order is deterministic and explicit** - Python's threading
library is missing strict conventions for controlled and orderly shutdown.
Each thread can shutdown on its own terms, but is expected to do so expediently.
* All threads are required to accept a `please_stop` signal; are
expected to test it in a timely manner; and expected to exit when signalled.
* All threads have a parent - The parent is responsible for ensuring their children get the `please_stop` signal, and are dead, before stopping themselves. This responsibility is baked into the thread spawning process,
so you need not deal with it unless you want.
2. Uses [**Signals**](#signal-class) to simplify logical
dependencies among multiple threads, events, and timeouts.
3. **Logging and Profiling is Integrated** - Logging and exception handling
is seamlessly integrated: This means logs are centrally handled, and thread
safe. Parent threads have access to uncaught child thread exceptions, and
the cProfiler properly aggregates results from the multiple threads.
### What's it used for
A good amount of time is spent waiting for underlying C libraries and OS
services to respond to network and file access requests. Multiple
threads can make your code faster, despite the GIL, when dealing with those
requests. For example, by moving logging off the main thread, we can get
up to 15% increase in overall speed because we no longer have the main thread
waiting for disk writes or remote logging posts. Please note, this level of
speed improvement can only be realized if there is no serialization happening
at the multi-threaded queue.
### Do not use Async
[Actors](http://en.wikipedia.org/wiki/Actor_model) are easier to reason about than [async tasks](https://docs.python.org/3/library/asyncio-task.html). Mixing regular methods and co-routines (with their `yield from` pollution) is dangerous because:
1. calling styles between synchronous and asynchronous methods can be easily confused
2. actors can use blocking methods, async can not
3. there is no way to manage resource priority with co-routines.
4. stack traces are lost with co-routines
5. async scope easily escapes lexical scope, which promotes bugs
Python's async efforts are still immature; a re-invention of threading functionality by another name. Expect to experience a decade of problems that are already solved by threading; [here is an example](https://www.python.org/dev/peps/pep-0550/).
## Reading
* Fibers were an async experiment using a stack, as opposed to the state-machine-based async Python uses now. It does not apply to my argument, but is an interesting read: [[Fibers are] not an appropriate solution for writing scalable concurrent software](http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2018/p1364r0.pdf)
## Writing threaded functions
All threaded functions must accept a `please_stop` parameter, which is a `Signal` to indicate the desire to stop. The function should check this signal often, and do it's best to promptly return.
#### Simple work loop
For threaded functions that perform small chunks of work in some loop; the chunks are small enough that they will complete soon enough. Simply check the `please_stop` signal at the start of each loop:
def worker(p1, p2, please_stop):
while not please_stop:
do_some_small_chunk_of_work(p1)
#### One-time work
Sometimes, threads are launched to perform low priority, one-time work. You may not need to check the `please_stop` signal:
def worker(p1, p2, please_stop):
do_some_work_and_exit(p1, p2)
#### Passing signals to others
There are many times a more complex `please_stop` checks are required. For example, we want to wait on an input queue for the next task. Many of the methods in `mo-threads` accept `Signals` instead of timeouts so they return quickly when signalled. You may pass the `please_stop` signal to these methods, or make your own. Be sure to check if the method returned because it is done, or it returned because it was signaled to stop early.
```python
def worker(source, please_stop):
while not please_stop:
data = source.pop(till=please_stop)
if please_stop: # did pop() return because of please_stop?
return
chunk_of_work(data)
```
#### Combining signals
Work might be done on some regular interval: The threaded function will sleep for a period and perform some work. In these cases you can combine Signals and `wait()` on either of them:
```python
def worker(please_stop):
while not please_stop:
next_event = Till(seconds=1000)
(next_event | please_stop).wait()
if please_stop: # is wait done because of please_stop?
return
chunk_of_work()
```
## Spawning threads
Most threads will be declared and run in a single line. It is much like Python's threading library, except it demands a name for the thread:
thread = Thread.run("name", function, p1, p2, ...)
Sometimes you want to separate creation from starting:
thread = Thread("name", function, p1, p2, ...)
thread.start()
### `join()` vs `release()`
Once a thread is created, a few actions can be performed with the thread object:
* `join()` - Join on `thread` will make the caller thread wait until `thread` has stopped. Then, return the resulting value or to re-raise `thread`'s exception in the caller.
result = thread.join() # may raise exception
* `release()` - Will ignore any return value, and post any exception to logging. Tracking is still performed; released threads are still properly stopped. You may still `join()` to guarantee the caller will wait for thread completion, but you risk being too late: The thread may have already completed and logged it's failure.
thread.release() # release thread resources asap, when done
* `stopped.wait()` - Every thread has a `stopped` Signal, which can be used for coordination by other threads. This allows a thread to wait for another to be complete and then resume. No errors or return values are captured
thread.stopped.wait()
### Registering Threads
Threads created without this module can call your code; You want to ensure these "alien" threads have finished their work, released the locks, and exited your code before stopping. If you register alien threads, then `mo-threads` will ensure the alien work is done for a clean stop.
def my_method():
with RegisterThread():
t = Thread.current() # we can now use mo-threads on this thread
print(t.name) # a name is always given to the alien thread
## Synchronization Primitives
There are three major aspects of a synchronization primitive:
* **Resource** - Monitors and locks can only be owned by one thread at a time
* **Binary** - The primitive has only two states
* **Irreversible** - The state of the primitive can only be set, or advanced, never reversed
The last, *irreversibility* is very useful, but ignored in many threading
libraries. The irreversibility allows us to model progression; and
we can allow threads to poll for progress, or be notified of progress.
These three aspects can be combined to give us 8 synchronization primitives:
* `- - -` - Semaphore
* `- B -` - Event
* `R - -` - Monitor
* `R B -` - **[Lock](#lock-class)**
* `- - I` - Iterator/generator
* `- B I` - **[Signal](#signal-class)** (or Promise)
* `R - I` - Private Iterator
* `R B I` - Private Signal (best implemented as `is_done` Boolean flag)
## `Lock` Class
Locks are identical to [threading monitors](https://en.wikipedia.org/wiki/Monitor_(synchronization)), except for two differences:
1. The `wait()` method will **always acquire the lock before returning**. This is an important feature, it ensures every line inside a `with` block has lock acquisition, and is easier to reason about.
2. Exiting a lock via `__exit__()` will **always** signal a waiting thread to resume. This ensures no signals are missed, and every thread gets an opportunity to react to possible change.
3. `Lock` is **not reentrant**! This is a feature to ensure locks are not held for long periods of time.
**Example**
```python
lock = Lock()
while not please_stop:
with lock:
while not todo:
lock.wait(seconds=1)
# DO SOME WORK
```
In this example, we look for stuff `todo`, and if there is none, we wait for a second. During that time others can acquire the `lock` and add `todo` items. Upon releasing the the `lock`, our example code will immediately resume to see what's available, waiting again if nothing is found.
## `Signal` Class
[The `Signal` class](mo_threads/signals.py) is a binary semaphore that can be signalled only once; subsequent signals have no effect.
* It can be signalled by any thread;
* any thread can wait on a `Signal`; and
* once signalled, all waiting threads are unblocked, including all subsequent waiting threads.
* A Signal's current state can be accessed by any thread without blocking.
`Signal` is used to model thread-safe state advancement. It initializes to `False`, and when signalled (with `go()`) becomes `True`. It can not be reversed.
Signals are like a Promise, but more explicit
| Signal | Promise | Python Event |
|:------------:|:------------------:|:------------:|
| s.go() | p.resolve() | e.set() |
| s.then(f) | p.then(m) | |
| s.wait() | await p | e.wait() |
| bool(s) | | e.is_set() |
| s & t | Promise.all(p, q) | |
| s | t | Promise.race(p, q) | |
Here is simple worker that signals when work is done. It is assumed `do_work` is executed by some other thread.
```python
class Worker:
def __init__(self):
self.is_done = Signal()
def do_work(self):
do_some_work()
self.is_done.go()
```
You can attach methods to a `Signal`, which will be run, just once, upon `go()`. If already signalled, then the method is run immediately.
```python
worker = Worker()
worker.is_done.then(lambda: print("done"))
```
You may also wait on a `Signal`, which will block the current thread until the `Signal` is a go
```python
worker.is_done.wait()
print("worker thread is done")
```
`Signals` are first class, they can be passed around and combined with other Signals. For example, using the `__or__` operator (`|`): `either = lhs | rhs`; `either` will be triggered when `lhs` or `rhs` is triggered.
```python
def worker(please_stop):
while not please_stop:
#DO WORK
user_cancel = Signal("user cancel")
...
worker(user_cancel | Till(seconds=360))
```
`Signal`s can also be combined using logical and (`&`): `both = lhs & rhs`; `both` is triggered only when both `lhs` and `rhs` are triggered:
```python
(workerA.stopped & workerB.stopped).wait()
print("both threads are done")
```
### Differences from Python's `Event`
* `Signal` is not reversable, while `Event` has a `clear()` method
* `Signal` allows function chaining using the `then` method
* Complex signals can be composed from simple signals using boolean logic
## `Till` Class
[The `Till` class](mo-threads/till.py) (short for "until") is a special `Signal` used to represent timeouts.
```python
Till(seconds=20).wait()
Till(till=Date("21 Jan 2016").unix).wait()
```
Use `Till` rather than `sleep()` because you can combine `Till` objects with other `Signals`.
**Beware that all `Till` objects will be triggered before expiry when the main thread is asked to shutdown**
## `Command` Class
If you find process creation is too slow, the `Command` class can be used to recycle existing processes. It has the same interface as `Process`, yet it manages a `bash` (or `cmd.exe`) session for you in the background.
Raw data
{
"_id": null,
"home_page": "https://github.com/klahnakoski/mo-threads",
"name": "mo-threads",
"maintainer": null,
"docs_url": null,
"requires_python": null,
"maintainer_email": null,
"keywords": null,
"author": "Kyle Lahnakoski",
"author_email": "kyle@lahnakoski.com",
"download_url": "https://files.pythonhosted.org/packages/04/38/5aee22746f19decfb5db85ea08c802f6a8dabd0bbb38bb9200060bcdc88c/mo_threads-6.672.25036.tar.gz",
"platform": null,
"description": "\r\n# More Threads!\r\n\r\n[](https://pypi.org/project/mo-threads/)\r\n[](https://github.com/klahnakoski/mo-threads/actions/workflows/build.yml)\r\n[](https://coveralls.io/github/klahnakoski/mo-threads?branch=dev)\r\n[](https://pepy.tech/project/mo-threads)\r\n\r\n## Module `threads`\r\n\r\nThe main benefits over Python's threading library is:\r\n\r\n1. **Shutdown order is deterministic and explicit** - Python's threading \r\nlibrary is missing strict conventions for controlled and orderly shutdown. \r\nEach thread can shutdown on its own terms, but is expected to do so expediently.\r\n * All threads are required to accept a `please_stop` signal; are \r\n expected to test it in a timely manner; and expected to exit when signalled.\r\n * All threads have a parent - The parent is responsible for ensuring their children get the `please_stop` signal, and are dead, before stopping themselves. This responsibility is baked into the thread spawning process, \r\n so you need not deal with it unless you want.\r\n2. Uses [**Signals**](#signal-class) to simplify logical \r\ndependencies among multiple threads, events, and timeouts.\r\n3. **Logging and Profiling is Integrated** - Logging and exception handling \r\nis seamlessly integrated: This means logs are centrally handled, and thread \r\nsafe. Parent threads have access to uncaught child thread exceptions, and \r\nthe cProfiler properly aggregates results from the multiple threads.\r\n\r\n\r\n### What's it used for\r\n\r\nA good amount of time is spent waiting for underlying C libraries and OS\r\nservices to respond to network and file access requests. Multiple\r\nthreads can make your code faster, despite the GIL, when dealing with those\r\nrequests. For example, by moving logging off the main thread, we can get\r\nup to 15% increase in overall speed because we no longer have the main thread\r\nwaiting for disk writes or remote logging posts. Please note, this level of\r\nspeed improvement can only be realized if there is no serialization happening\r\nat the multi-threaded queue. \r\n\r\n### Do not use Async\r\n\r\n[Actors](http://en.wikipedia.org/wiki/Actor_model) are easier to reason about than [async tasks](https://docs.python.org/3/library/asyncio-task.html). Mixing regular methods and co-routines (with their `yield from` pollution) is dangerous because:\r\n\r\n1. calling styles between synchronous and asynchronous methods can be easily confused\r\n2. actors can use blocking methods, async can not\r\n3. there is no way to manage resource priority with co-routines.\r\n4. stack traces are lost with co-routines\r\n5. async scope easily escapes lexical scope, which promotes bugs \r\n\r\nPython's async efforts are still immature; a re-invention of threading functionality by another name. Expect to experience a decade of problems that are already solved by threading; [here is an example](https://www.python.org/dev/peps/pep-0550/). \r\n\r\n## Reading\r\n\r\n* Fibers were an async experiment using a stack, as opposed to the state-machine-based async Python uses now. It does not apply to my argument, but is an interesting read: [[Fibers are] not an appropriate solution for writing scalable concurrent software](http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2018/p1364r0.pdf)\r\n\r\n\r\n## Writing threaded functions\r\n\r\nAll threaded functions must accept a `please_stop` parameter, which is a `Signal` to indicate the desire to stop. The function should check this signal often, and do it's best to promptly return. \r\n\r\n#### Simple work loop\r\n\r\nFor threaded functions that perform small chunks of work in some loop; the chunks are small enough that they will complete soon enough. Simply check the `please_stop` signal at the start of each loop:\r\n\r\n def worker(p1, p2, please_stop):\r\n while not please_stop:\r\n do_some_small_chunk_of_work(p1)\r\n \r\n#### One-time work\r\n \r\nSometimes, threads are launched to perform low priority, one-time work. You may not need to check the `please_stop` signal: \r\n \r\n def worker(p1, p2, please_stop):\r\n do_some_work_and_exit(p1, p2)\r\n\r\n#### Passing signals to others\r\n \r\nThere are many times a more complex `please_stop` checks are required. For example, we want to wait on an input queue for the next task. Many of the methods in `mo-threads` accept `Signals` instead of timeouts so they return quickly when signalled. You may pass the `please_stop` signal to these methods, or make your own. Be sure to check if the method returned because it is done, or it returned because it was signaled to stop early.\r\n \r\n```python \r\ndef worker(source, please_stop):\r\n while not please_stop:\r\n data = source.pop(till=please_stop)\r\n if please_stop: # did pop() return because of please_stop?\r\n return\r\n chunk_of_work(data)\r\n```\r\n\r\n#### Combining signals\r\n \r\nWork might be done on some regular interval: The threaded function will sleep for a period and perform some work. In these cases you can combine Signals and `wait()` on either of them:\r\n\r\n```python \r\ndef worker(please_stop):\r\n while not please_stop:\r\n next_event = Till(seconds=1000)\r\n (next_event | please_stop).wait()\r\n if please_stop: # is wait done because of please_stop?\r\n return\r\n chunk_of_work()\r\n```\r\n\r\n## Spawning threads\r\n\r\nMost threads will be declared and run in a single line. It is much like Python's threading library, except it demands a name for the thread: \r\n\r\n thread = Thread.run(\"name\", function, p1, p2, ...)\r\n \r\nSometimes you want to separate creation from starting:\r\n\r\n thread = Thread(\"name\", function, p1, p2, ...)\r\n thread.start()\r\n \r\n \r\n### `join()` vs `release()`\r\n\r\nOnce a thread is created, a few actions can be performed with the thread object:\r\n\r\n* `join()` - Join on `thread` will make the caller thread wait until `thread` has stopped. Then, return the resulting value or to re-raise `thread`'s exception in the caller.\r\n\r\n result = thread.join() # may raise exception\r\n\r\n* `release()` - Will ignore any return value, and post any exception to logging. Tracking is still performed; released threads are still properly stopped. You may still `join()` to guarantee the caller will wait for thread completion, but you risk being too late: The thread may have already completed and logged it's failure.\r\n\r\n thread.release() # release thread resources asap, when done\r\n \r\n* `stopped.wait()` - Every thread has a `stopped` Signal, which can be used for coordination by other threads. This allows a thread to wait for another to be complete and then resume. No errors or return values are captured\r\n\r\n thread.stopped.wait()\r\n \r\n### Registering Threads\r\n\r\nThreads created without this module can call your code; You want to ensure these \"alien\" threads have finished their work, released the locks, and exited your code before stopping. If you register alien threads, then `mo-threads` will ensure the alien work is done for a clean stop. \r\n\r\n def my_method():\r\n with RegisterThread():\r\n t = Thread.current() # we can now use mo-threads on this thread \r\n print(t.name) # a name is always given to the alien thread \r\n\r\n\r\n## Synchronization Primitives\r\n\r\nThere are three major aspects of a synchronization primitive:\r\n\r\n* **Resource** - Monitors and locks can only be owned by one thread at a time\r\n* **Binary** - The primitive has only two states\r\n* **Irreversible** - The state of the primitive can only be set, or advanced, never reversed\r\n\r\nThe last, *irreversibility* is very useful, but ignored in many threading\r\nlibraries. The irreversibility allows us to model progression; and\r\nwe can allow threads to poll for progress, or be notified of progress. \r\n\r\nThese three aspects can be combined to give us 8 synchronization primitives:\r\n\r\n* `- - -` - Semaphore\r\n* `- B -` - Event\r\n* `R - -` - Monitor\r\n* `R B -` - **[Lock](#lock-class)**\r\n* `- - I` - Iterator/generator\r\n* `- B I` - **[Signal](#signal-class)** (or Promise)\r\n* `R - I` - Private Iterator \r\n* `R B I` - Private Signal (best implemented as `is_done` Boolean flag)\r\n\r\n## `Lock` Class\r\n\r\nLocks are identical to [threading monitors](https://en.wikipedia.org/wiki/Monitor_(synchronization)), except for two differences: \r\n\r\n1. The `wait()` method will **always acquire the lock before returning**. This is an important feature, it ensures every line inside a `with` block has lock acquisition, and is easier to reason about.\r\n2. Exiting a lock via `__exit__()` will **always** signal a waiting thread to resume. This ensures no signals are missed, and every thread gets an opportunity to react to possible change.\r\n3. `Lock` is **not reentrant**! This is a feature to ensure locks are not held for long periods of time.\r\n\r\n**Example**\r\n```python\r\nlock = Lock()\r\nwhile not please_stop:\r\n with lock:\r\n while not todo:\r\n lock.wait(seconds=1)\r\n # DO SOME WORK\r\n```\r\nIn this example, we look for stuff `todo`, and if there is none, we wait for a second. During that time others can acquire the `lock` and add `todo` items. Upon releasing the the `lock`, our example code will immediately resume to see what's available, waiting again if nothing is found.\r\n\r\n\r\n## `Signal` Class\r\n\r\n[The `Signal` class](mo_threads/signals.py) is a binary semaphore that can be signalled only once; subsequent signals have no effect.\r\n * It can be signalled by any thread; \r\n * any thread can wait on a `Signal`; and \r\n * once signalled, all waiting threads are unblocked, including all subsequent waiting threads. \r\n * A Signal's current state can be accessed by any thread without blocking.\r\n \r\n`Signal` is used to model thread-safe state advancement. It initializes to `False`, and when signalled (with `go()`) becomes `True`. It can not be reversed. \r\n\r\nSignals are like a Promise, but more explicit \r\n\r\n| Signal | Promise | Python Event |\r\n|:------------:|:------------------:|:------------:|\r\n| s.go() | p.resolve() | e.set() |\r\n| s.then(f) | p.then(m) | |\r\n| s.wait() | await p | e.wait() |\r\n| bool(s) | | e.is_set() |\r\n| s & t | Promise.all(p, q) | |\r\n| s | t | Promise.race(p, q) | |\r\n\r\n\r\nHere is simple worker that signals when work is done. It is assumed `do_work` is executed by some other thread.\r\n\r\n```python\r\nclass Worker:\r\n def __init__(self):\r\n self.is_done = Signal()\r\n \r\n def do_work(self):\r\n do_some_work()\r\n self.is_done.go()\r\n```\r\n\r\nYou can attach methods to a `Signal`, which will be run, just once, upon `go()`. If already signalled, then the method is run immediately.\r\n\r\n```python\r\nworker = Worker()\r\nworker.is_done.then(lambda: print(\"done\"))\r\n```\r\n\r\nYou may also wait on a `Signal`, which will block the current thread until the `Signal` is a go\r\n\r\n```python\r\nworker.is_done.wait()\r\nprint(\"worker thread is done\")\r\n```\r\n\r\n`Signals` are first class, they can be passed around and combined with other Signals. For example, using the `__or__` operator (`|`): `either = lhs | rhs`; `either` will be triggered when `lhs` or `rhs` is triggered.\r\n\r\n```python\r\ndef worker(please_stop):\r\n while not please_stop:\r\n #DO WORK \r\n\r\nuser_cancel = Signal(\"user cancel\")\r\n...\r\nworker(user_cancel | Till(seconds=360))\r\n```\r\n\r\n`Signal`s can also be combined using logical and (`&`): `both = lhs & rhs`; `both` is triggered only when both `lhs` and `rhs` are triggered:\r\n\r\n```python\r\n(workerA.stopped & workerB.stopped).wait()\r\nprint(\"both threads are done\")\r\n```\r\n\r\n### Differences from Python's `Event`\r\n\r\n* `Signal` is not reversable, while `Event` has a `clear()` method\r\n* `Signal` allows function chaining using the `then` method\r\n* Complex signals can be composed from simple signals using boolean logic \r\n\r\n\r\n\r\n## `Till` Class\r\n\r\n[The `Till` class](mo-threads/till.py) (short for \"until\") is a special `Signal` used to represent timeouts. \r\n\r\n```python\r\nTill(seconds=20).wait()\r\nTill(till=Date(\"21 Jan 2016\").unix).wait()\r\n```\r\n\r\nUse `Till` rather than `sleep()` because you can combine `Till` objects with other `Signals`. \r\n\r\n**Beware that all `Till` objects will be triggered before expiry when the main thread is asked to shutdown**\r\n\r\n\r\n## `Command` Class\r\n\r\nIf you find process creation is too slow, the `Command` class can be used to recycle existing processes. It has the same interface as `Process`, yet it manages a `bash` (or `cmd.exe`) session for you in the background.\r\n\r\n \r\n",
"bugtrack_url": null,
"license": "MPL 2.0",
"summary": "More Threads! Simpler and faster threading.",
"version": "6.672.25036",
"project_urls": {
"Homepage": "https://github.com/klahnakoski/mo-threads"
},
"split_keywords": [],
"urls": [
{
"comment_text": "",
"digests": {
"blake2b_256": "27ca41dffb14bdff42167a3774ed79424103fbd71c2014c74d5f442525adc6b3",
"md5": "27695d5021dddddac3310c549d545b28",
"sha256": "acc9cabdc938ba30aab44ab54de05c09641ad380d2076c720e76083a67ca9e9b"
},
"downloads": -1,
"filename": "mo_threads-6.672.25036-py3-none-any.whl",
"has_sig": false,
"md5_digest": "27695d5021dddddac3310c549d545b28",
"packagetype": "bdist_wheel",
"python_version": "py3",
"requires_python": null,
"size": 48059,
"upload_time": "2025-02-05T23:34:02",
"upload_time_iso_8601": "2025-02-05T23:34:02.971314Z",
"url": "https://files.pythonhosted.org/packages/27/ca/41dffb14bdff42167a3774ed79424103fbd71c2014c74d5f442525adc6b3/mo_threads-6.672.25036-py3-none-any.whl",
"yanked": false,
"yanked_reason": null
},
{
"comment_text": "",
"digests": {
"blake2b_256": "04385aee22746f19decfb5db85ea08c802f6a8dabd0bbb38bb9200060bcdc88c",
"md5": "4b1e10c3941806f1e85da5a22f88aae5",
"sha256": "234e57f9bd265632e16ed04b1477ce14d1997d51be041a9e10a345eaa417e386"
},
"downloads": -1,
"filename": "mo_threads-6.672.25036.tar.gz",
"has_sig": false,
"md5_digest": "4b1e10c3941806f1e85da5a22f88aae5",
"packagetype": "sdist",
"python_version": "source",
"requires_python": null,
"size": 45127,
"upload_time": "2025-02-05T23:34:04",
"upload_time_iso_8601": "2025-02-05T23:34:04.319033Z",
"url": "https://files.pythonhosted.org/packages/04/38/5aee22746f19decfb5db85ea08c802f6a8dabd0bbb38bb9200060bcdc88c/mo_threads-6.672.25036.tar.gz",
"yanked": false,
"yanked_reason": null
}
],
"upload_time": "2025-02-05 23:34:04",
"github": true,
"gitlab": false,
"bitbucket": false,
"codeberg": false,
"github_user": "klahnakoski",
"github_project": "mo-threads",
"travis_ci": false,
"coveralls": true,
"github_actions": true,
"lcname": "mo-threads"
}
JSON
