2017-01-06 4 views
0

私の理解では、単一の使用のためuv_asyncの適切な使用は、以下のことです:単一使用のuv_asyncコールバックにuv_async_sendの代わりにuv_closeを使用しますか?

  1. uv_async_tハンドルを割り当てます。
  2. 割り当て済みハンドルのuv_async_initを呼び出します。
  3. コールuv_async_sendをコールしてコールバックをスケジュールします。
  4. uv_closeを使用してハンドルの登録を解除します。
  5. 閉じるコールバックでuv_async_tハンドルを削除します。たとえば、

uv_async_t *handle = (uv_async_t*)malloc(sizeof(uv_async_t)); 
    uv_async_init(&uvLoop, handle, [](uv_async_t *handle) { 
     // My async callback here 
     uv_close((uv_handle_t*)handle, [](uv_handle_t* handle) { 
      free(handle); 
     }); 
    }); 
    uv_async_send(&asyncCb->uvAsync); 

私が集まる何から、uv_closeはuvLoopで非同期と呼ばれています。したがって、私は、イベントループ内の2つのコールバックキューイングを避けるために次の操作を行うように誘惑しています:

uv_async_t *handle = (uv_async_t*)malloc(sizeof(uv_async_t)); 
    uv_async_init(&uvLoop, handle, nullptr); 
    uv_close((uv_handle_t*)handle, [](uv_handle_t* handle) { 
     // My async callback here 
     free(handle); 
    }); 

をこれを行う他の誰であり、それは安全であると考えていますか?

答えて

1

達成しようとしていることは何ですか?複数のスレッドを使用する必要がありますか?その場合、uv_closeはスレッドセーフではないため、これは機能しません。

今後、ループ内でコールバックをスケジュールするだけであれば、uv_idle_tにチェックを入れてください。作成して破棄するのではなく、必要に応じてキューを使用してハンドルを開始/停止することもできます。

+1

ありがとう、これは私が必要とした答えです。 'uv_async_send'はスレッドセーフですが、' uv_close'はそうではないとは思いませんでした。 'uv_close'のコールバックに依存しているコードの2番目のバージョンは、スレッドセーフではなく、最初のバージョンのコードに代わるものではありません。私のテストでは、おそらく生産で爆発するのを待っている純粋な運から出てきていました。 – GaspardP

関連する問題