You are viewing a plain text version of this content. The canonical link for it is here.
Posted to notifications@couchdb.apache.org by GitBox <gi...@apache.org> on 2017/12/18 13:01:27 UTC

[GitHub] eiri commented on a change in pull request #1067: Fix mango native proc crash

eiri commented on a change in pull request #1067: Fix mango native proc crash
URL: https://github.com/apache/couchdb/pull/1067#discussion_r157477887
 
 

 ##########
 File path: src/mango/src/mango_native_proc.erl
 ##########
 @@ -363,4 +366,35 @@ validate_index_info(IndexInfo) ->
             [invalid_index | Results0]
         end
     end, [], IdxTypes),
-    lists:member(valid_index, Results).
\ No newline at end of file
+    lists:member(valid_index, Results).
+
+
+-ifdef(TEST).
+
+-include_lib("eunit/include/eunit.hrl").
+
+handle_garbage_collect_cast_test() ->
+    Pid = self(),
+    {_, TracerRef} = spawn_monitor(fun() ->
+        erlang:trace(Pid, true, [garbage_collection]),
+        receive {trace, Pid, gc_start, _} ->
+            erlang:trace(Pid, false, [garbage_collection]),
+            exit(gc_start)
+        end
+    end),
+    erlang:yield(),
+    ?assertEqual({noreply, []}, handle_cast(garbage_collect, [])),
+    receive
+        {'DOWN', TracerRef, _, _, Msg} -> ?assertEqual(gc_start, Msg)
 
 Review comment:
   No, no, it's different.
   
   We spawn and monitor a new process that sets a trace on the test process, because process can't trace itself. Then in the test process we call a garbage collection by executing `handle_cast(garbage_collect, [])` and asserting that we are getting proper `noreply` response. The tracer receives `gc_start` trace message, indicating that its target (the test process) started a garbage collection and exits with reason `gc_start`. Because we are monitoring it in our test process, we are receiving its exit reason and can assert that it was indeed for a garbage collection.
   
   Interesting bit here is `erlang:yield()` - we need to give a scheduler a chance to run the tracer process or gc will be finished before the trace set.
   
   Conceptually it's is not different from when we are mocking module with `meck` and then waiting for some of its functions to be called, but I had to use trace here because you can't mock `garbage_collection`. Plus, unlike mock, this is a real deal, we are checking actual, not simulated functionality.
   

----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
users@infra.apache.org


With regards,
Apache Git Services