Re: Yet another threading question...
Re: Yet another threading question...
- Subject: Re: Yet another threading question...
- From: Stamenkovic Florijan <email@hidden>
- Date: Fri, 27 Feb 2009 09:23:00 -0400
On Feb 26, 2009, at 22:19, Chuck Hill wrote:
I thought of making an EOEditingContext subclass that encapsulates
a thread and it does all it's work on that single thread,
regardless of which thread a method call to it is made on. It would
entail overriding all the methods in the EOEditingContext to do
something like a producer / consumer setup. I think that if well
made, it would introduce minimal overhead, as any inactive thread
would be waiting, and would insulate the EOEditingContext from the
multithreading outside of it. I have not thought it through very
well (though I am pretty sure it can be made), so, can anyone think
of unexpected bad side-effects?
Also, this is happening on the client side, though I am not sure if
that makes much of a difference for this.
Not really sure what that is going to achieve. Thread X altering
the state of an EC or thread X getting thread Y to do it seems the
same.
In that scenario: nothing.
But, if I have threads X and Y altering the state of an EC (which I do
at the moment, with disastrous results), and instead getting threads X
and Y to get thread Z to alter the state of the EC would accomplish
that the EC is only ever touched by thread Z. In short, I could have
50 threads doing work in a single EC, but the EC only ever getting
touched by one. Which I hope would solve the deadlock / exception
problem I have at the moment. Plus, since only thread would be
actually doing the work, it would have the side effect of task queuing
and synchronization on the EC. See my point?
- still trying :) I was just about to ditch all the multithreading
in my client app, saw how much it'd slow it down and make it less
user friendly, and I just can't do it without another shot at it...
Aw, just make a web app! :-P
And have most problems already solved?!? Use Wonder?!? Have an easy
life?!? How could you even suggest that???
F
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden