Other languages uses thread pool, instead of creating new thread.

In Python,loop.run_in_executor uses thread pool.

https://docs.python.org/3.13/library/asyncio-eventloop.html#asyncio.loop.run_in_executor

2025年6月24日(火) 8:12 Mild Shock <janbu...@fastmail.fm>:
>
> So what does:
>
> stats = await asyncio.to_thread(os.stat, url)
>
> Whell it calls in a sparate new secondary thread:
>
> os.stat(url)
>
> It happends that url is only a file path, and
> the file path points to an existing file. So the
> secondary thread computs the stats, and terminates,
>
> and the async framework hands the stats back to
> the main thread that did the await, and the main
> thread stops his waiting and continues to run
>
> cooperatively with the other tasks in the current
> event loop. The test case measures the wall time.
> The results are:
>
>  > node.js: 10 ms (usual Promises and stuff)
>  > JDK 24: 50 ms (using Threads, not yet VirtualThreads)
>  > pypy: 2000 ms
>
> I am only using one main task, sequentially on
> such await calles, with a couple of file, not
> more than 50 files.
>
> I could compare with removing the async detour,
> to qualify the async I/O detour overhead.
>
> Mild Shock schrieb:
> > Hi,
> >
> > async I/O in Python is extremly disappointing
> > and an annoying bottleneck.
> >
> > The problem is async I/O via threads is currently
> > extremly slow. I use a custom async I/O file property
> > predicate. It doesn't need to be async for file
> >
> > system access. But by some historical circumstances
> > I made it async since the same file property routine
> > might also do a http HEAD request. But what I was
> >
> > testing and comparing was a simple file system access
> > inside a wrapped thread, that is async awaited.
> > Such a thread is called for a couple of directory
> >
> > entries to check a directory tree whether updates
> > are need. Here some measurement doing this simple
> > involving some little async I/O:
> >
> > node.js: 10 ms (usual Promises and stuff)
> > JDK 24: 50 ms (using Threads, not yet VirtualThreads)
> > pypy: 2000 ms
> >
> > So currently PyPy is 200x times slower than node.js
> > when it comes to async I/O. No files were read or
> > written in the test case, only "mtime" was read,
> >
> > via this Python line:
> >
> > stats = await asyncio.to_thread(os.stat, url)
> >
> > Bye
> >
> > Mild Shock schrieb:
> >>
> >> Concerning virtual threads the only problem
> >> with Java I have is, that JDK 17 doesn't have them.
> >> And some linux distributions are stuck with JDK 17.
> >>
> >> Otherwise its not an idea that belongs solely
> >> to Java, I think golang pioniered them with their
> >> goroutines. I am planning to use them more heavily
> >>
> >> when they become more widely available, and I don't
> >> see any principle objection that Python wouldn't
> >> have them as well. It would make async I/O based
> >>
> >> on async waithing for a thread maybe more lightweight.
> >> But this would be only important if you have a high
> >> number of tasks.
> >>
> >> Lawrence D'Oliveiro schrieb:
> >>> Short answer: no.
> >>>
> >>> <https://discuss.python.org/t/add-virtual-threads-to-python/91403>
> >>>
> >>> Firstly, anybody appealing to Java as an example of how to design a
> >>> programming language should immediately be sending your bullshit
> >>> detector
> >>> into the yellow zone.
> >>>
> >>> Secondly, the link to a critique of JavaScript that dates from 2015,
> >>> from
> >>> before the language acquired its async/await constructs, should be
> >>> another
> >>> warning sign.
> >>>
> >>> Looking at that Java spec, a “virtual thread” is just another name for
> >>> “stackful coroutine”. Because that’s what you get when you take away
> >>> implicit thread preemption and substitute explicit preemption instead.
> >>>
> >>> The continuation concept is useful in its own right. Why not concentrate
> >>> on implementing that as a new primitive instead?
> >>>
> >>
> >
> --
> https://mail.python.org/mailman3//lists/python-list.python.org



-- 
Inada Naoki  <songofaca...@gmail.com>
-- 
https://mail.python.org/mailman3//lists/python-list.python.org

Reply via email to