Tony Finch wrote:
On Wed, 21 Jun 2006, Simon Peyton-Jones wrote:
New worker threads are spawned on as needed. You'll need as many of
them as you have simultaneously-blocked foreign calls. If you have 2000
simultaneously-blocked foreign calls, you'll need 2000 OS threads to
support them,
Li, Peng wrote:
On 6/21/06, Simon Peyton-Jones [EMAIL PROTECTED] wrote:
New worker threads are spawned on as needed. You'll need as many of
them as you have simultaneously-blocked foreign calls. If you have 2000
simultaneously-blocked foreign calls, you'll need 2000 OS threads to
support
Seth Kurtzberg wrote:
Thanks for the info. I don't compare thread IDs. At the moment I merely print
out the thread ID in a trace message. Shortly I will be using the thread ID
when a need arises to kill a thread. It sounds like the rollover is harmless
for these situations.
When you
| -Original Message-
| From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]
| On Behalf Of Bulat Ziganshin
| Sent: 21 June 2006 07:00
| To: Seth Kurtzberg
| Cc: glasgow-haskell-users@haskell.org
| Subject: Re[2]: FFI: number of worker threads?
|
| Hello Seth,
|
| Wednesday, June 21, 2006, 7
Li, Peng wrote:
The paper Extending the Haskell FFI with Concurrency mentioned the
following in Section 6.3:
GHC's run-time system employs one OS thread for every bound thread;
additionally, there is a variable number of so-called worker OS
threads that are used to execute the unbounded
Seth Kurtzberg wrote:
I have a related question. The docs state that in some environments O/S
threads are used when the -threaded flag is used with ghc, and non-O/S threads
are used otherwise (presumably these are non-preemptive). Does this apply as
well to the worker threads that are the
Bulat Ziganshin wrote:
Wednesday, June 21, 2006, 7:18:48 AM, you wrote:
Seth and Li, look at
http://www.cse.unsw.edu.au/~chak/haskell/ghc/comm/rts-libs/multi-thread.html
That's a good page, but it's about 2 generations out of date
unfortunately. Some of it is relevant, but many of the
Seth Kurtzberg wrote:
Another related question. I have some threaded applications running
which are servers and run continuously. A thread is spawned for each
new connection, and the thread exits when the client terminates.
I've noticed that the thread ID increases. On one process I
Simon Marlow wrote:
Seth Kurtzberg wrote:
Another related question. I have some threaded applications running
which are servers and run continuously. A thread is spawned for each
new connection, and the thread exits when the client terminates.
I've noticed that the thread ID
| (page http://www.cse.unsw.edu.au/~chak/haskell/ghc/comm/ contains
| commentaries about GHC internals)
|
| And ideally all that material should be on the wiki.
In fact we are looking for volunteers to do the HTML - Wiki
translation. No new writing reqd!
Simon
Hello Simon,
Wednesday, June 21, 2006, 4:10:46 PM, you wrote:
| (page http://www.cse.unsw.edu.au/~chak/haskell/ghc/comm/ contains
| commentaries about GHC internals)
|
| And ideally all that material should be on the wiki.
In fact we are looking for volunteers to do the HTML - Wiki
Simon,
Thanks for the response.
The doc I was referring to is the library haddock doc for Control.Concurrent.
Seth
On Wed, 21 Jun 2006 12:41:52 +0100
Simon Marlow [EMAIL PROTECTED] wrote:
Seth Kurtzberg wrote:
I have a related question. The docs state that in some environments O/S
Simon,
Thanks for the info. I don't compare thread IDs. At the moment I merely print
out the thread ID in a trace message. Shortly I will be using the thread ID
when a need arises to kill a thread. It sounds like the rollover is harmless
for these situations.
When you talk about comparing
On 6/21/06, Simon Peyton-Jones [EMAIL PROTECTED] wrote:
New worker threads are spawned on as needed. You'll need as many of
them as you have simultaneously-blocked foreign calls. If you have 2000
simultaneously-blocked foreign calls, you'll need 2000 OS threads to
support them, which probably
On Wed, 2006-06-21 at 12:31 -0400, Li, Peng wrote:
On 6/21/06, Simon Peyton-Jones [EMAIL PROTECTED] wrote:
New worker threads are spawned on as needed. You'll need as many of
them as you have simultaneously-blocked foreign calls. If you have 2000
simultaneously-blocked foreign calls,
On 6/21/06, Duncan Coutts [EMAIL PROTECTED] wrote:
On linux, epoll scales very well with minimal overhead. Using multiple
OS threads to do blocking IO would not scale in the case of lots of idle
socket connections, you'd need one OS thread per socket.
On Linux, OS threads can also scale very
On Wed, 21 Jun 2006, Simon Peyton-Jones wrote:
New worker threads are spawned on as needed. You'll need as many of
them as you have simultaneously-blocked foreign calls. If you have 2000
simultaneously-blocked foreign calls, you'll need 2000 OS threads to
support them, which probably won't
On Wed, 2006-06-21 at 17:55 +0100, Duncan Coutts wrote:
So I'd suggest the best approach is to keep the existing multiplexing
non-blocking IO system and start to take advantage of more scalable IO
APIs on the platforms we really care about (either select/poll
replacements or AIO).
FYI: Felix
Hello,
The paper Extending the Haskell FFI with Concurrency mentioned the
following in Section 6.3:
GHC's run-time system employs one OS thread for every bound thread;
additionally, there is a variable number of so-called worker OS
threads that are used to execute the unbounded (lightweight)
Another related question. I have some threaded applications running which are
servers and run continuously. A thread is spawned for each new connection, and
the thread exits when the client terminates.
I've noticed that the thread ID increases. On one process I checked today I am
up to
20 matches
Mail list logo
