[Mono-list] Re: Consuming unmanged code, global/static variables,
robertj at gmx.net
Thu Feb 23 10:46:02 EST 2006
> What about C# wrapper classes that were singletons and had locks that would
> take care of race conditions, initializing the library in global?
Now I understand what you are looking for: an entry point to
initialize the lib. This entry point exists even for ASP.NET apps:
it's the method
protected void Application_Start(Object sender, EventArgs e)
But you can use a singleton for the initialization as well.
> On 2/23/06, Robert Jordan <robertj at gmx.net> wrote:
>>> Looking for some guidelines on consuming some of our library (in C) into
>>> .NET for use with ASP.NET pages
>>> I'm concerned about our global and static variables that are needed in
>>> of our libraries. In a single threaded C# application this would be no
>>> problem. Initialize the libraries at startup, destroy on close.
>>> But for ASP.NET pages, how would I handle initialization, since multiple
>>> pages are being served at the same time making use of these libraries?
>> Are your native libraries thread safe? If yes, you usually don't
>> have to care about the initialization. If they are not: welcome to a
>> world of pain.
>>> Would I initiailze for each page request as needed in the C# code behind
>>> page? Or is this going to have problems when multiple requests are
>> It won't work. Go ahead and fix the native library. Everything
>> else is a waste of time.
>>> Also what about a function that contains a static variable?
>> You have to rewrite them to use a TLS slot instead of the
>> static variable. If the content of the static variable is
>> thread invariant, a lock for its initialization might be sufficient.
>> The same has to be done with static variables outside
>> of functions as well.
>>> Basically these are the questions I have, but I just can't find any
>>> resources to explain how ASP.NET applications are threaded, and how it
>>> effect consumption of unmanaged libraries. If anyone can even point me
>>> the right direction I'd be very grateful.
>> The threading model of ASP.NET is quite straightforward for
>> the developer: one cannot predict by which thread the request
>> will be handled. This implies that the ASP.NET consumer has
>> to deal with concurrency all the time.
>> Mono-list maillist - Mono-list at lists.ximian.com
> Mono-list maillist - Mono-list at lists.ximian.com
More information about the Mono-list