News for hackers. Stuff that matters.

A comment on Show HN: Bringing multithreading to Python's async event loop. Parent comment

Re:Show HN: Bringing multithreading to Python's async event ... by mywittyname on Thursday October 03, 2024 @11:35AM (#41731725)
Sure, this works sometimes. But sometimes you have mountains of code and infrastructure dedicated to one platform, and it's worth the effort to round off the occasional square peg in the interest of operational simplicity/consistency.

I've been using ThreadPoolExecutors in Python for a while now. They seem to work pretty well for my use cases. Granted, my use cases don't require things like shared memory segments; I use as_* functions under concurrent.futures to recombine the data as needed. Honestly, I prefer the futures functions as I don't need to think about deadlocks.

[ Parent | on HN ]
Re:Show HN: Bringing multithreading to Python's async event ... by game_the0ry on Thursday October 03, 2024 @12:07PM (#41732005)
> Sure, this works sometimes. But sometimes you have mountains of code and infrastructure dedicated to one platform, and it's worth the effort to round off the occasional square peg in the interest of operational simplicity/consistency.

I agree with this, this is a fair trade off, but not the direction I would go as a matter of preference.

[ Parent | on HN ]
Re:Show HN: Bringing multithreading to Python's async event ... by maest on Thursday October 03, 2024 @02:27PM (#41733440)
What's the alternative, though?

1. Rewrite the whole thing 2. Carve out the high perf component into a separate system and also deal with the overhead of marshalling data between two different systems?

[ Parent | on HN ]