Re: [boost] Re: Threads: what I wrote...

From: Kevlin Henney (kevlin_at_[hidden])
Date: 2000-08-09 11:16:27

In message <20000809155851.15667.qmail_at_[hidden]>, Dietmar
Kuehl <dietmar_kuehl_at_[hidden]> writes
>If 'f()' is a function, I would consider this to be more natural:
>
>  spawn_thread(f);

Definitely, or something similar.

>... and if 'f()' takes three arguments, I would still consider
>
>  spawn_thread(f, 1, 2, 3);

I would be inclined towards either recasting f as a function object
type:

  spawn_thread(f(1, 2, 3));

Or using a few adaptors, ie a little bit of currying.

>(where the arguments can be of arbitrary types) to be more natural.
>However, I would strongly prefer it if there would be one common method
>to create a thread on which a platform independent library implements
>all those nifty and fancy other tools! ... or, put differently, a naive
>port of the Boost Threading library to some underlying threading
>library should be a matter of implement a dozen pretty trivial classes
>and/or functions. Built on top of this rock solid basis we can create
>whatever our damag^H^H^H^H^H brains spin off.
>
>Hm, maybe we would end up with two interfaces:
>- A generic requirement oriented user interface to the Boost Threading
>  Library.
>- A base library to ease porting on which the BTL is implemented.

Given that almost all rational (?) C threading APIs work in terms of a
function pointer that can handle an arg, there is very little magic
required to accommodate the NullaryFunctionObject approach. So the split
you suggest is not required at that level. However, on BTL we could
build an asynch function framework that returned deferred result
proxies.
____________________________________________________________

  Kevlin Henney                   phone:  [phone]
  Curbralan Ltd                   mobile: [phone]
  kevlin_at_[hidden]            fax:    [phone]
____________________________________________________________