Additional boundary function proposal

[txdv]

It is very annoying to create a boundary in order to use it for blocking API, so here is a proposal for some nicer API:

https://gist.github.com/1064214

What do you think?

Too bad there are no extensions for static methods.

[ghost]

I like neither your BoundaryExtensions, nor your proposed boundary.

The extensions, because they force the user to supply a success callback (null allowed, yes), which has no use. The success callback will be executed on the context thread, so one might just as well combine action and success beforehand. Not to speak of the ThreadPool thing, which the boundary is supposed to handle.

The proposed boundary because it keeps strong references to every context it knows. Doing that, it keeps contexts alive needlessly. One could use a conditional weak table of boundary instances instead, that might fix at least that part.

[txdv]

The idea is to run something in another thread, probably something that blocks, and then return back to the context thread without blocking? How do I achieve that combining action and success beforehand? I have no idea how to achieve it otherwise, can you show me how the boundary is supposed to handle it?

[ghost]

First you fork your longrunning action out to the threadpool or some other means of threading. There you see whether your action succeeds or not. Only then do you place a delegate into the boundary to be executed on the thread of the target context, and that delegate already knows the outcome of the action.

// stuff
ThreadPool.QueueUserWorkItem(delegate {
  // long running stuff, store result in res
  Boundary.Instance.ExecuteOnTargetLoop(delegate {
    // do something with res
  }
});

[ghost]

What i was trying to say: you don't need the wrapper layer named BoundaryExtensions. "Joining the boundary" means "joining the context thread", so while your extensions do the right thing, they confuse.