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.