HawtDispatch and long running async tasks called from Runnables

50 views
Skip to first unread message

mongonix

unread,
Jul 25, 2011, 4:39:32 AM7/25/11
to hawtdi...@googlegroups.com
Hi,

I'm new to HawtDispatch and have the following question:

In my application model I have sessions. Each session may need to execute a number of Runnable tasks, strictly in the same order as they were submitted.
Each session's task may invoke another asynchronous task (e.g. long running IO, invocation of an external service, etc). Once such an async task task is completed, it would invoke a user-defined completion callback. The session task that invoked an asynchronous task is considered to be done only after the async task has completed and async task's completion callback has been invoked. Of course, it would be nice to implement this  by doing a non-blocking waiting. In any case, only after the current session task is over, the next session task can be invoked.

My idea is to use HawtDispatch SerialQueues for session tasks, because this would guarantee the in-order execution per session. But I do not quite understand how I can implement the described semantics of waiting for completion of asynchronous tasks  before continuing with a next task from a serial queue.
My guess, I need to use suspend/resume on the serial queue representing a session. But I'm not sure.
For example, just after I trigger an async task from the session task, I could do suspend() on this queue inside the session task, which puts the queue on hold. Later, when the async task invokes the completion callback, the callback would do resume() on the session queue and thus allow it to proceed with the next task.

Would it work this way? Or may be there are better alternatives? May be it can be done somehow with custom dispatch sources?

Any feedback is appreciated!


Hiram Chirino

unread,
Jul 25, 2011, 10:15:09 AM7/25/11
to hawtdi...@googlegroups.com
I think the suspend/resume should work ok as you described.

The alternative would to internally queue requests. So basically on
every request you would enqueue into an internally maintained list, an
only execute new session requests when there are no outstanding async
tasks.


Regards,
Hiram

FuseSource
Web: http://fusesource.com/

christian.posta

unread,
Jul 25, 2012, 12:25:10 PM7/25/12
to hawtdi...@googlegroups.com, hi...@hiramchirino.com
I believe that's correct. You should be able to call resume from a different thread. If I believe what you're asking is this:

   @Test

    public void testResumeFromDifferentThread() throws InterruptedException {

        DispatchQueue queue = dispatcher.createQueue("test");

        final HawtCustomDispatchSource<Integer, Integer> source =

                new HawtCustomDispatchSource<Integer, Integer>(dispatcher, EventAggregators.INTEGER_ADD, queue);


        RunnableCountDownLatch eventHandler = new RunnableCountDownLatch(1){

            @Override

            public void run() {

                assertEquals(new Integer(9), source.getData());

                super.run();    //To change body of overridden methods use File | Settings | File Templates.

            }

        };


        source.setEventHandler(eventHandler);


        DispatchQueue globalQueue = dispatcher.getGlobalQueue();

        globalQueue.execute(new Task() {

            @Override

            public void run() {

                source.resume();

            }

        });


        globalQueue.execute(new Task() {

            @Override

            public void run() {

                source.merge(4);

                source.merge(5);

            }

        });


        assertTrue(eventHandler.await(1, TimeUnit.SECONDS));


    }


On Wednesday, July 25, 2012 3:37:52 AM UTC-4, JAmes Atwill wrote:

On Monday, July 25, 2011 7:15:09 AM UTC-7, Hiram Chirino wrote:
I think the suspend/resume should work ok as you described.

This tiny detail makes serial queues make sense to me. Thank you!

Am I right in believing that I should be able to call .resume() from an unrelated thread without any issues?

  JAmes

Reply all
Reply to author
Forward
0 new messages