ansaurus

Question

Find the foreground thread from the background thread.

Answer 1

+6 A:

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.

Jon Skeet 2009-03-27 10:28:37

and if the thread is threadpooled ?

alexl 2009-03-27 11:12:42

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?

Jon Skeet 2009-03-27 11:20:19

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)

alexl 2009-03-27 11:28:41

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.

Jon Skeet 2009-03-27 11:34:42

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)

alexl 2009-03-27 11:40:29

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 2009-03-27 11:53:18

(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.)

Jon Skeet 2009-03-27 11:54:49

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

alexl 2009-03-27 12:00:03

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

Jon Skeet 2009-03-27 12:05:30

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 2009-03-27 12:11:55

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

alexl 2009-03-27 12:12:48

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 :)

Jon Skeet 2009-03-27 12:32:58

ansaurus

tags:

views:

answers:

Find the foreground thread from the background thread.

related questions