Back to Questions
1.1k
views2
comments
How asyncronous is Async.Run?
f#async

I am having a bit of trouble reading the available lib-code (I am a newbie after all). What I would like to know is if a construct like the following will actually be executed on the thread calling foo, or will it trigger a threadpool thread into action:

1

let foo (n:int) = Async.Run( async { return n } )

The question might seem odd, but I need to know since I want to run a mailbox processor in a thread I have spawned myself, and the Receive() function returns a Async<'a> which I need to run to get the actual message.

.

Async.Run will queue a new item in the thread pool (at the moments its the thread pool, this might change but its an unimportant detail). It will then wait for this work item to be signal that it's finished collect the result. The work item be executed is your 'async { return n }'. You can also Async.Spawn if you do not want to block the current thread while the workflow executes.

The point of mailboxes is not to try and runthem on one physical o/s thread but rather let them run as a workflow. Let me try and explain that better :) Receive() returns Async<'a> so you need to use it within a workflow with the let! binding to get the value. This is so that if Receive blocks (i.e. no messages in the queue) it does not block the thread, instead a completion is registered in the thread pool which will be activated when the next message arrives.

In short implment your mailbox as a workflow. Call the .Start() method and it will run in the background. No need to worry about spawning a thread yourself.

Cheers,
Rob

By on 7/30/2008 3:17 AM ()

Thanks Robert. That answers my question :-)

But somehow it would be nice to be able to read a message without involving the threadpool. If for instance I have n ("ordinary") threads running and their only means of communication is by message passing, it seems rather overkill to queue an item on the threadpool each time I want to read a message.
The solution is of course to implement my own processing mechanism, like I have done with MPAPI, but I just thought that since F# has all these new, interesting and great features (computational expresssions, or workflows, being one of them) to write concurrent software, an approach to message passing more like Erlang was possible.

And maybe it will - like you wrote yourself the threadpool might not be used in the future.

Thanks again
/Frank

By on 7/30/2008 3:33 AM ()

    Topic tags

    IntelliFactory Offices Copyright (c) 2011-2012 IntelliFactory. All rights reserved.
    Home | Products | Consulting | Trainings | Blogs | Jobs | Contact Us | Terms of Use | Privacy Policy | Cookie Policy     		Built with WebSharper