Contexts AThread?

[Justin Case]

Just a quickie.. Indy 10.6.3.3..

Is there a way to access the AThread of TIdContext?

I've been unable to find it..

Thanks

JC

[rlebeau]

Just a quickie.. Indy 10.6.3.3..

FYI, the current version is 10.6.3.6 (soon 10.6.3.7).

Is there a way to access the AThread of TIdContext?

Yes. You can typecast the TIdContext.Yarn property to TIdYarnOfThread (from the IdSchedulerOfThread unit). It has a public Thread property.

[Justin Case]

Ah yes, what is this Yarn thing btw? - v9 and 8 never had it!

[rlebeau]

what is this Yarn thing btw? - v9 and 8 never had it!

Yes, it was something new added in v10. The idea was to separate tasks from threads, so a task could be handled across multiple threads, and a thread could handle multiple tasks. The Yarn is what helped link them together.

In reality, that didn't work out so well (see the abandoned SuperCore package, which tried to introduce fiber support). So, things are still 1 task per thread. Although, there is a thread pool in v10, so a thread can handle multiple tasks at least, just not in parallel.

[Justin Case]

Hang about..

So a thread could handle multiple tasks (whatever a task is meant to be lol) and a task could be handled across multiple threads..

A context could be passed between multiple threads and multiple threads could pass around a context..

but a thread pool has threads that can handle multiple tasks.. even though multiple tasks cannot be be run on multiple threads... lol.

I'm sure someone could come up with a better tongue twister than me..

[rlebeau]

So a thread could handle multiple tasks (whatever a task is meant to be lol)

In this case, a task is a client context (TIdContext derives from TIdTask). But the API was abstracted so in theory it could be used for other purposes.

and a task could be handled across multiple threads. A context could be passed between multiple threads and multiple threads could pass around a context.

That was the plan, but it never materialized that way.

but a thread pool has threads that can handle multiple tasks.

Yes. When a thread is done with a task, the thread can go back in the pool until a new task is ready for it.

That being said, the pooling is not the default behavior. You have to use the TIdSchedulerOfThreadPool component to get the behavior.