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 talk
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 the
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, which
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: Fe
Hello Peng,
Wednesday, June 21, 2006, 8:31:41 PM, you wrote:
> My wish is to have a future GHC implementation that (a) uses blocking
> I/O directly provided by the OS, and (b) provides more control over OS
> threads and the internal worker thread pool. Using blocking I/O will
> simplify the curr
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'
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, 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 call
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
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
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
>
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
| > (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
_
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 increa
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 che
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 deta
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 su
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 (l
y" and for "FFI", so you can add to those. Thanks
Simon
| -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: n
Hello Seth,
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
it may answer some of your questions
(page http://www.cse.unsw.edu.au/~chak/haskell/ghc/comm/ contains
commentaries about GHC internal
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 threa
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 subject of this email?
On
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
23 matches
Mail list logo
