------- Bug moved to this database by vrajkumar@novell.com 2005-10-10 16:54 -------

This bug previously known as bug DEFECT000311053 at remedy/
remedy/show_bug.cgi?id=DEFECT000311053
Originally filed under the NDS SDK product and LDAP C SDK component.

---------
<remedy_version_found_in> BLANK </remedy_version_found_in>
---------
<remedy_milestone> BLANK </remedy_milestone>
---------
<remedy_details> 
When LibC based, we still need to support other clib based libraries
that wrap our calls inside their own exported functions.  Many bad
Clib Libraries migrate incoming threads into their context with
SetThreadGroupID.

ex:
    FooAPI()
     {
        orgCtx = SetThreadGroupID(myCtx); (migrate to my context)

                   (do work - call ldap apis )

         SetThreadGroupID(orgCtx);  (migrate back)
      }

This architecture causes problems for use when we are LibC based
because LibC doesn't understand the migration that occurred
inside FooAPI above us.  To get around this problem we'll detect
if the thread is a Clib Thread and call the appropriate Clib
GetNLMHandle call which does understand the migration.

NOTE:  A properly designed library which encapsulates our libraries
        doesn't need to use SetThreadGroupID garbage, but many
       currently do.

 </remedy_details>
---------
<remedy_notes> dsward (  8/20/02 4:17:10 PM  Testing -  ) Fixed by
      using libc's get_app_type call to determine what type of thread is
      calling into us.  If it is a clib based thread, we switch and use a
      clib call (getNLMHandle) to determine which nlm is coming in.  The clib
      getNLMHandle is aware to the technique of using setThreadGroupID to
      allow a thread to assume an existing Clib context.

 </remedy_notes>