ThreadStart and ThreadPool

  • Thread starter Thread starter Franz
  • Start date Start date
....> 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).
Click to expand...

See one of my code examples above to get the same behavior as the thread
pool. Create that helper class once and use it.
 
William Stacey said:
...> 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.
Click to expand...

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.
 
Jon Skeet said:
....

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?
Click to expand...

Yes, unless threads were a language construct (as in Ada).
 
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.
Click to expand...

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.
Click to expand...

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.
 
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?
Click to expand...

Can do this using modified version of my StartThread helper.
 
Back
Top