This is a most interesting post.

For starters, we can get rid of the Alternate session storage TLS. I
probably should put it under a compiler directive and default it to being
left out. It's need is rare so if you want to butcher the sources a bit to
save resources that would be fine.

I do need a TLS slot for the rest of what IBO does, per each session. The
ISAPI manager allows up to 32 modules to be cached in memory so you might
want to consider setting this pooled module count to a lesser number.

What are the symptoms you observe here?

I would be happy to give your situation here special attention. Feel free to
begin private correspondence with me and I will take care of reporting back
to the list all of our findings.

Thanks,
Jason Wharton
CPS - Mesa AZ
http://www.ibobjects.com

----- Original Message -----
From: <cb_nos@...>
To: <IBObjects@yahoogroups.com>
Sent: Wednesday, October 10, 2001 8:39 AM
Subject: [IBO] TLS Slots


> hi,
>
> i need to learn about the way IBO handles the use of tls (thread
> local storage) slots - we are building isapi dlls and running out of
> them.
> what i know so far is that each (multithreaded) dll attaching to a
> process uses one tls slot (of which i have only 64), also each dll
> that loads another one does.
>
> looking at the ibo sources i found this ReserveSessionHookRef in the
> initialization clause of ib_session. it seems to allocate 2 slots
> (each one for hAlternateSession and hDefaultSession) .. would this
> explain why loading of my dlls consumes at least 3 slots?
>
> still questionable is if these allocations were done for every
> webmodule instance, since the ib_session component sits in the
> webmodule?
>
> i also logged the available tls slots for each module call, which
> resulted in some really strange behaviour: results where completely
> different, e.g. some action of A.DLL would report 23 available slots,
> while another action of A.DLL would show 17. this is continous, so i
> get a report like
>
> A.DLL/a1 - 23 tls slots
> A.DLL/a2 - 17 tls slots <-- strange?
> A.DLL/a1 - 23 tls slots <-- even more strange
> B.DLL/a3 - 19 tls slots <-- assume first load, uses 3 slots
> A.DLL/a1 - 20 tls slots
> A.DLL/a2 - 14 tls slots
> A.DLL/a1 - 20 tls slots
> (...and so on)
>
> actions a1 & a2 are in the main unit of A.DLL, so i don't really
> understand how these two calls could come to different results?
>
> unfortunately this is a very important issue to us, we have a fairly
> high number of dlls in use and can definitely not stuff them
> together..!
>
> regards
> christoph
> ____________________________________________
> if the world didn't suck, we'd all fall off.
>
>
>
>
>
>
>
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
>
>