Boost logo

Boost :

From: bill_kempf (williamkempf_at_[hidden])
Date: 2002-01-25 10:16:15


--- In boost_at_y..., "terekhov" <terekhov_at_d...> wrote:
> --- In boost_at_y..., "bill_kempf" <williamkempf_at_h...> wrote:
> > --- In boost_at_y..., "terekhov" <terekhov_at_d...> wrote:
> > > [...]
> > > > > May I just repost
> > > > > the last message I've sent to you yesterday (you did not
> reply
> > > > > yet)?
> > > >
> > > > Feel free to. I haven't replied because there wasn't much
new
> > that
> > > I
> > > > felt required replies, and I'm hip deep in other things :).
> > >
> > > To: "William Kempf" <williamkempf_at_h...>
> > > cc: bdawes_at_a..., pdimov_at_m...
> > > From: Alexander Terekhov/Germany/IBM_at_IBMDE
> > > Subject: Re: Boost.Thread/thread_ptr ?!
> >
> > [snip]
> >
> > Like I said before, I don't see too much that needs an immediate
> > reply, though I'm looking forward to hearing other voices on
this.
> > However, I'd like to ask an important question: is there anything
> in
> > the redesign I've posted that makes building your thread_ptr
design
> > on top of it either difficult or impossible? The answer to this,
I
> > think, will help to illuminate problems in the direction I'm
> leaning
> > towards now, as well as to decide whether or not either of us is
> > totally off base here.
>
> The answer would be definitely:
>
> "no, there's nothing in the posted design that makes things
> difficult or impossible to use it as the basis for implementing
> my design"

OK, that helps, I think.

> *IF* the posted design would fully support (and be
> compatible wrt C-level cancel/exit/etc functions in
> my OLD code) the full functionality (*100%*) of the
> following *mandatory* (not optional) POSIX threading
> calls (thread/mutex/cond attributes aside for now,
> these are just pthread_* calls used in the current
> version of mythread.c):

I don't think it's going to be possible to fully support the C-level
cancel/exit/etc. methods of any "native" API in Boost.Threads, though
that would be the plan for any proposal to the standard.
 
> [***] BTW, the last time I've looked at it,
> WIN32 version was lacking proper sync. in
> boost::condition's destructor.

Could you send a diff showing the fix you think is required?
 
> P.S. Perhaps you already know it, but
> apropos your recent "standardization",
> POSIX++ vs WIN32, lowest common denominator,
> etc discussions, I just would like to
> briefly mention that MS-WIN threading++
> MODEL/API is now THE ECMA-*STANDARD*:
> (doc.list w/o Mutex/Auto-/Manual-events,etc stuff)

Yes, I'm aware of this. Thanks. It's another effort we'll have to
consider through out here.

> Directory of G:\C#\tr-084\2001tc39-020b\System\Threading
>
> 10/02/2001 12:44p 546,816 Interlocked.doc
> 11/14/2001 05:38p 40,519 Interlocked.pdf
> 10/02/2001 12:44p 568,832 Monitor.doc
> 11/14/2001 05:36p 56,873 Monitor.pdf
> 10/02/2001 12:44p 30,208
> SynchronizationLockException.doc
> 11/14/2001 05:36p 20,093
> SynchronizationLockException.pdf
> 10/02/2001 12:44p 686,080 Thread.doc
> 11/14/2001 05:36p 138,010 Thread.pdf
> 10/02/2001 12:45p 26,624 ThreadAbortException.doc
> 11/14/2001 05:36p 17,664 ThreadAbortException.pdf
> 10/02/2001 12:44p 26,624 ThreadPriority.doc
> 11/14/2001 05:36p 18,577 ThreadPriority.pdf
> 10/02/2001 12:45p 21,504 ThreadStart.doc
> 11/14/2001 05:37p 13,391 ThreadStart.pdf
> 10/02/2001 12:44p 34,816 ThreadState.doc
> 11/14/2001 05:37p 23,926 ThreadState.pdf
> 10/02/2001 12:45p 32,256 ThreadStateException.doc
> 11/14/2001 05:37p 21,215 ThreadStateException.pdf
> 10/02/2001 12:45p 22,016 Timeout.doc
> 11/14/2001 05:37p 14,015 Timeout.pdf
> 10/02/2001 12:45p 546,816 Timer.doc
> 11/14/2001 05:37p 41,480 Timer.pdf
> 10/02/2001 12:45p 23,552 TimerCallback.doc
> 11/14/2001 05:37p 14,747 TimerCallback.pdf
> 10/02/2001 12:43p 530,944 WaitHandle.doc
> 11/14/2001 05:35p 30,514 WaitHandle.pdf
> 26 File(s) 3,548,112 bytes
>
> more info:
>
> http://www.cs.umd.edu/~pugh/java/memoryModel/archive/0938.html

Thanks for the link.

Bill Kempf


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk