RE: [Dotgnu-libjit] Leaking of one struct jit_thread_control per thread.

[GARCIA DE SORIA LUCENA, JUAN JESUS]

Hi, Aleksey.

> -----Original Message-----
> From: Aleksey Demakov [mailto:address@hidden 
> Sent: Wednesday, May 28, 2008 9:44
> 
> As a side note, the common wisdom is to use thread pools 
> rather than create/destroy threads indefinitely.
> Probably the original libjit author had this idea that the 
> number of libjit threads  will be bound to some reasonably 
> small number so the problem of reclaiming thread local memory 
> was not addressed in the first place.

I know, and I understand perfectly that this 16-byte (in our win32
measurements) per thread may legitimately be a petty priority when
considering efforts on other, far more useful features. Moreover when
solving this issue transparently in all the target platforms seems to be
a tricky issue, with a difficulty that's not in proportion to the gains
obtained.

> If there were a function like jit_thread_deatch() that frees 
> the current thread's TLS data would it resolve the problem 
> for you or you need automatic deallocation?

Actually we are using libjit in a very deep and abstracted code
hierarchy that has nothing to do with threads. The part of the
infrastructure that creates and destroys the threads doesn't know at all
about libjit. It simply loads calculation modules dynamically. Some of
these may link against libjit whereas some others may not. This means
that we can't use the jit_thread_detach() approach without making our
mostly agnostic infrastructure code know about libjit too.

So we would prefer some automatic approach to this.

Or we could move to a thread-pool based approach. We use this kind of
approach in some other, more modern, servers that we have. The problem
is that the one affected this time is a little bit of 'semi-legacy' code
that would require a good revamp in order to work on thread pools.


In either case it remains to be seen whether the effort of any of these
approaches is justified. I think that right now we can live with a
16-byte/request leak without any actual disruption in the service we
provide to our users.


Regards, and thanks in advance,

   Juan Jesus.