[erlang-questions] testing asynchronous code

[Mazen Harake]

Hi, Sorry for jumping in...

This method (of using sync calls for testing async functionality) is 
sometimes dangerous, specially when you don't know the internals of the 
system. The simple reason is that a sync call can block something that 
wasn't suppose to be blocked and therefore you get 1) the possibility of 
deadlocks which wouldn't be a problem when run "live" and 2) a slight 
different semantics because you won't get the same behaviour of 
race-conditions which can appear due to the async nature of the 
processes communicating.

My 2 cents :)

/Mazen

On 20/04/2010 08:27, Martin DeMello wrote:
> On Mon, Apr 19, 2010 at 8:21 PM, David Mercer<dmercer@REDACTED>  wrote:
>    
>> I assume your issue is that you cannot test system state right after a cast
>> because its processing is asynchronous?
>>      
> Yes, exactly.
>
>    
>> Alternatively, you might could[1] add a "sync" call into the server, which
>> does nothing, but you know when it returns that all prior casts have been
>> processed, and then you can make your asserts on the server or system state,
>> etc.  (If the casts are passing processing off to other processes, the sync
>> call would have to "sync" with them before returning.)
>>      
> This was one of the things I thought about, but have no idea how to
> actually do. Where and how would I keep track of which casts are
> processed? Here's a concrete example - I have a tree of objects in
> mnesia, which I want to run some cleanup code on. So I send a cast to
> the root, which cleans up its associated resource, sends casts to all
> its children, and then deletes itself from the db, and so on
> recursively. How would I go about syncing on that? For example, I
> could wait for all the objects to be deleted from the db, but that's
> syncing on the "side effects" of the cast, rather than explicitly when
> the function it calls has returned.
>
> martin
>
> ________________________________________________________________
> erlang-questions (at) erlang.org mailing list.
> See http://www.erlang.org/faq.html
> To unsubscribe; mailto:erlang-questions-unsubscribe@REDACTED
>
>    

---------------------------------------------------

---------------------------------------------------

WE'VE CHANGED NAMES!

Since January 1st 2010 Erlang Training and Consulting Ltd. has become ERLANG SOLUTIONS LTD.

www.erlang-solutions.com