ThreadStart and ThreadPool

[William Stacey [MVP]]

....> when you have no desire to be able to stop the workers anyway. To take

my earlier example situation, you can certainly give the "request"
object the "client" object which should be used to send it, and then
either move all the sending code into the request or make the request
call the client asking it to send it, but it's less natural, IMO, than
asking the client (of which I only *want* one instance) to send the
request (which will vary).

See one of my code examples above to get the same behavior as the thread
pool. Create that helper class once and use it.

 

[Jon Skeet [C# MVP]]

...> when you have no desire to be able to stop the workers anyway. To take

See one of my code examples above to get the same behavior as the thread
pool. Create that helper class once and use it.

Oh you certainly *can* do it in any number of ways, and I don't have
any problem doing that in practice. I was just arguing with your claim
that it was always better OO practice *not* to use parameters, and that
it never bent your design out of shape to have to put everything in
state, or creating a helper class. It would be more natural in some
situations, such as the one I mentioned, to be able to use parameters.
It would lead to a cleaner design. Certainly in many other situations
the cleaner design uses state and no parameters anyway - I'm just
claiming that not all situations are like that.

 

[John Saunders]

....

And would you have done it that way if there'd been a type-safe way of
creating a new thread which called a particular method within Client
with a specific parameter? (Being able to pass a single object gets
half way, but doesn't give type safety.) Would you have done it that
way if threads *hadn't* been involved?

Yes, unless threads were a language construct (as in Ada).

 

[Jon Skeet [C# MVP]]

Yes, unless threads were a language construct (as in Ada).

I guess we'll have to agree to differ then.

 

[William Stacey [MVP]]

I was just arguing with your claim

that it was always better OO practice *not* to use parameters, and that
it never bent your design out of shape to have to put everything in
state, or creating a helper class.

I never said any of that. I said I prefer to wrap my threads because I
imply my own Interface on them with Start and Stop methods and is flexible
in terms of state, etc. I said a couple of times, people are free to do
what they want, as am I.

It would be more natural in some
situations, such as the one I mentioned, to be able to use parameters.
It would lead to a cleaner design. Certainly in many other situations
the cleaner design uses state and no parameters anyway - I'm just
claiming that not all situations are like that.

Not sure the point of rehashing this over and over. It is not there today,
unless you build a helper to abstract it the way the Threadpool does (as I
showed example of.) I have agreed that passing object(s) via threadstart
would be a good thing to have, but it is not there today.

 

[William Stacey [MVP]]

And would you have done it that way if there'd been a type-safe way of

creating a new thread which called a particular method within Client
with a specific parameter?

Can do this using modified version of my StartThread helper.