[Caml-list] Thread Local Storage

[Caml-list] Thread Local Storage

[Jonathan Roewen]

Hi,

I'm wondering if it'd be at all possible to somehow implement
something akin to TLS under the ocaml bytecode vmthreads package.

This is for having software-based processes, and globals whose
instances are unique to a given process.

Jonathan

Re: Thread Local Storage

[Vincenzo Ciancia]

Jonathan Roewen wrote:

> I'm wondering if it'd be at all possible to somehow implement
> something akin to TLS under the ocaml bytecode vmthreads package.
> 
> This is for having software-based processes, and globals whose
> instances are unique to a given process.

I don't know if there are better solutions but at least you can use an
hashtable or a balanced tree or whatever (protected by a mutex) indexed on
thread identifiers as reported by  "Thread.id (Thread.self ())" or
something similar.

Bye

Vincenzo

-- 
Please note that I do not read the e-mail address used in the from field but
I read vincenzo_ml at yahoo dot it
Attenzione: non leggo l'indirizzo di posta usato nel campo from, ma leggo
vincenzo_ml at yahoo dot it

Re: [Caml-list] Re: Thread Local Storage

[Jonathan Roewen]

> I don't know if there are better solutions but at least you can use an
> hashtable or a balanced tree or whatever (protected by a mutex) indexed on
> thread identifiers as reported by  "Thread.id (Thread.self ())" or
> something similar.

Yes, but that means that you need functions to lookup the values,
rather than having the value have process-dependent values globally.
Think like Sys.argv (etc) -- this'd require changes to the interfaces
(not such a big deal, since I have control over all interfaces).

But to go even further, having distinct descriptors for
stdin/stdout/stderr, then you could see where this would become
unstuck. Whilst I have code that can change the value transparently
for stdin/stdout/stderr, this'd make for a bigger process switch if I
had to do for all TLS values.

Perhaps what I need would require a change to the compiler and runtime
=/ What I'd also want to avoid, but I guess I'll have to face the
music....

Jonathan

Re: [Caml-list] Re: Thread Local Storage

[skaller]

On Tue, 2006-02-14 at 15:40 +1300, Jonathan Roewen wrote:
[on TLS]

I wonder why you need this? You're providing a new OS with new
build system, tools, etc.

TLS is entirely a legacy application backwards compatibility hack
designed to support badly designed C applications. It has no
function in new code and should NOT be supported in an OS layer
that doesn't need to support broken legacy apps.

Threads already have local storage -- their stacks. That's
all you need.

-- 
John Skaller <skaller at users dot sf dot net>
Felix, successor to C++: http://felix.sf.net

Re: [Caml-list] Re: Thread Local Storage

[Florian Weimer]

> TLS is entirely a legacy application backwards compatibility hack
> designed to support badly designed C applications.

TLS helps a lot on a certain register-starved architecture because you
don't need to keep a pointer to the thread data structure around in
case you don't need it (but called functions might).  And you still
need some thread-local variables for various management purposes.

Re: [Caml-list] Re: Thread Local Storage

[skaller]

On Tue, 2006-02-14 at 22:40 +0100, Florian Weimer wrote:
> > TLS is entirely a legacy application backwards compatibility hack
> > designed to support badly designed C applications.
> 
> TLS helps a lot on a certain register-starved architecture because you
> don't need to keep a pointer to the thread data structure around in
> case you don't need it (but called functions might). 

What's wrong with placing it on the stack? 

[Better not be anything wrong with it .. because Felix
actually does precisely that :]

-- 
John Skaller <skaller at users dot sf dot net>
Felix, successor to C++: http://felix.sf.net

Re: [Caml-list] Re: Thread Local Storage

[Florian Weimer]

> On Tue, 2006-02-14 at 22:40 +0100, Florian Weimer wrote:
>> > TLS is entirely a legacy application backwards compatibility hack
>> > designed to support badly designed C applications.
>> 
>> TLS helps a lot on a certain register-starved architecture because you
>> don't need to keep a pointer to the thread data structure around in
>> case you don't need it (but called functions might). 
>
> What's wrong with placing it on the stack? 

Do you suggest to add an implicit argument to all function calls?
Unless you can optimize it away if it's not needed, the TLS approach
should still be faster for typical code.