Find the foreground thread from the background thread.

When you are in the context of the background thread.

Thread.IsBackground == true

There is a way to find the foreground thread calling this background thread ?

Thanks for your help

Update: The thread created are background and handled by a threadpool (Inside the Workflow Foundation Runtime). I have no way to add the reference from the main thread inside each background thread. There is no way to find that foreground thread from the threadpool ?

From stackoverflow

• There's no such relationship. Any thread can create a new thread, including another background thread. After the new thread has been created, there's no relationship between the creating thread and the new thread. If you need to know which thread created the new thread, you'll need to pass that information in the ThreadStart.

  EDIT: For thread-pool threads, by the time any of your code is running I assume it's been specified by you as a task somewhere, in some way. If you need some information to be available (whether that's a thread ID or anything else) you need to put it in the context for that task.

  alexl : and if the thread is threadpooled ?

  Jon Skeet : I'm not sure what you want to know about it. You can pass the thread which created the current task as state, if you really need to. Why do you need this information in the first place?

  alexl : I'm dealing with nhibernate sessions, and a session must be provided by thread. So i try to have one session for the workflow thread and all his Activities. Because the Transaction is begining before the creation of the workflow and commited at the end of the workflow. (But this mean same session)

  Jon Skeet : So how are you specifying the delegate to call? Basically, that delegate needs to have all the information you'll need within the task. Provide it the session as part of the context.

  alexl : I don't use delegates, because the service and data layer are from a web application. I use an implementation of ISessionStorage that stores the session. For the web app it stores by httcontext sessionid, and i made my implementation to get the NH session by thread id (that's the problem)

  Jon Skeet : If you've got code running on the thread pool, you *are* using delegates. That's how the thread pool works - you give it a delegate, it executes the delegate on a thread pool thread. How are you specifying the work?

  Jon Skeet : (To clarify - *something* is using delegates. It may be that you're not doing so explicitly, but it's not obvious yet which bit of code is executing on the thread pool.)

  alexl : I mean i dun use delegate explicitly. The Workflow Foundation runtime create the workflow with createWorkflow, and under the hood must create a threadpool for executing this activities. That's why i can't pass any information of the foreground thread

  Jon Skeet : So how do you get *any* contextual information to your code? Surely you have some sort of context.

  alexl : Basicly the framework i ve develop on works like this. The service are passed to the workflow. The activities uses the services. But service persists info with the session stored in ISessionStorage. And sessionstorage return the session based on the thread of the caller

  alexl : Well solution have found is to persist information inside each activities and not at the end of the entire workflow

  Jon Skeet : Right - so basically your activity is the context here? Not sure whether I helped or not, but I'm glad you sorted it in the end :)