On 06.12 20:57, Tomasz Zielonka wrote:
> On Tue, Dec 06, 2005 at 02:52:03PM +, Joel Reymont wrote:
> > Well, I do need to have access to all those thread handles.
Since thread creation is inside IO anyways you might want to
look at Control.Concurrent.QSem which solves this in an
easy fashion.
On Tue, Dec 06, 2005 at 02:52:03PM +, Joel Reymont wrote:
> Well, I do need to have access to all those thread handles.
A TVar Int and a set/list of handles?
Best regards
Tomasz
--
I am searching for a programmer who is good at least in some of
[Haskell, ML, C++, Linux, FreeBSD, math] for w
Well, I do need to have access to all those thread handles.
On Dec 6, 2005, at 2:43 PM, Maarten Hazewinkel wrote:
I apologise if this doesn't make sense (I'm fairly new to Haskell),
but
wouldn't a single shared counter be sufficient for this?
Increment for each child launched.
Decrement by e
On 12/6/05, Joel Reymont <[EMAIL PROTECTED]> wrote:
> I'm trying to implement a better waitForChildren from the docs for
> Control.Concurrent.
>
> I would like to know when all the children exit, basically, and I
> thought it would be neat to try to do that with STM.
I apologise if this doesn't ma
I'm trying to implement a better waitForChildren from the docs for
Control.Concurrent.
I would like to know when all the children exit, basically, and I
thought it would be neat to try to do that with STM.
Is there an advantage to STM here?
Thanks, Joel
On Dec 6, 2005, at 1:29 PM,
On 06 December 2005 10:02, Joel Reymont wrote:
> Is it efficient to wait on a few thousand TMVars?
That depends... while waiting your thread consumes no CPU at all (of
course), and simply waiting on all those TVars only imposes a small
constant overhead on anyone updating one of the TVars (a TMVa