*** can only be called from the main thread about c-sharp-promise HOT 10 CLOSED

That's probably because C-Sharp-Promise does not resolve asynchronously but directly. I.e. when you resolve a promise from a second thread, the handlers will be called immediately. You need to make sure you resolve the promise only in the main thread, either by queueing your asynchronous result and processing it in the main thread and then resolve the promise. Or by using the PromiseTimer implementation. You'd still need to make the PromiseTimer implementation concurrency-safe by locking access to the queue. Then you could resolve your promises from other threads by using this schema:

void MyAsyncThreadFunc(Promise asyncEventFinishedPromise)
{
    // Do long calculations here...

    // Resolve the promise once given to the client which
    // started the async task
    MyPromiseTimer.WaitFor(0F).Then( () => {
        asyncEventFinished.Resolve();
    });
}

Edit:
Forgot to add you actually need to put your PromiseTimer somewhere. If you use Unity I suggest setting it up as a MonoBehaviour singleton that you can reference directly. Again, either make sure the singleton is threadsafe or just initialize your PromiseTimer immediately at application start before starting any other worker threads. There is lack of a more fully featured sample, if you're interested I could write one up.

from c-sharp-promise.

Thank you for the fast response. I figured it out that it is resolving in some other thread. I believe adding this to the api as out of the box function to any promise would be nice. Do you happen to have a feature request portal?

from c-sharp-promise.

I guess that is a question for @ashleydavis - I myself believe that the promises should always resolve asynchronously, i.e. there has to be a platform layer somewhere transparently for the user of the promises. But I myself am currently lost how such a platform layer could be implemented without creating restrictions. As the library is, it works out-of-the-box without the need to have a event loop like javascript has. Plugging one in without big effort would be a very nice feature but the needs for the platform layer would be very different based on what you want to do. E.g. having a platform layer per-thread or enforcing promises to be always resolved on the main thread etc.. I think PromiseTimer already provides a good tool to provide asynchronous resolve where needed and if required one could always fork the library and go down into the guts to enforce asynchronous resolve on every promise.

from c-sharp-promise.

@zsoi if you got the time could you please provide a more detailed sample as I tried to implement your suggestion and failed.

from c-sharp-promise.

@paveldk I quickly typed this together: https://gist.github.com/zsoi/2de0f2f36fc3f7995786
I don't have time to test it, just wrote it down, so maybe there are some bugs. The ThreadsafePromiseTimer is basically the implementation from RSG.Promise but with a delayed insertion of new timers at the start of each Update.
You can quickly try it out by adding a GameObject with the UnityPromisePlatformLayer component to your scene and then enqueue the resolves by calling UnityPromisePlatformLayer.Timer.Wait(0F).Then( () => myAsyncPromise.Resolve() )

I'll try making that more stable tomorrow, I have needs for this myself ;-)

from c-sharp-promise.

@zsoi Thanks for handling this discussion, although I have one small correction. It's not quite right to say C-Sharp-Promise does not resolve asynchronously but directly.

This promise library will resolve asynchronously or directly depending on the situation and the code that is actually triggering the resolve or reject. We were careful not to tie the promise library to one method or another to make sure that it is generally useful to the most number of people possible.

@paveldk C-Sharp-Promise has no knowledge of threads. Of course it can be used with threads or not depending on your requirements.

The basic rule is this:

The thread where the promise is resolved or rejected is the thread where the then or catch will be invoked.

If you need to marshall your handlers back to the main thread, then that is a simple problem to solve. I recommend the dispatcher pattern. I plan to write a short blog post on this pattern soon, so stay tuned to http://www.what-could-possibly-go-wrong.com if you are interested in that.

We are reluctant to add an event loop or direct support for threading because it places too many requirements on how the promise library is used. And it is not difficult to build your own event loop or dispatcher system. After all we built the promise timer which was a later extension to the C# promise library (until we wrote the promises article, the promise timer lived in code base of the project it was implemented for and wasn't moved to github until the article was done).

from c-sharp-promise.

@zsoi Keep us updated how testing goes for your modified promise timer class.

from c-sharp-promise.

@paveldk Blog-post on the dispatcher pattern: http://www.what-could-possibly-go-wrong.com/the-dispatcher-pattern/

Please let me know if the information is useful or any other feedback you may have.

from c-sharp-promise.

I like your use of the Dispatcher pattern much better than my ab-use of the PromiseTimer! It's solving the same problem at a lower level with less overhead.

from c-sharp-promise.

Thank you very much both for the effort. Great article!

from c-sharp-promise.