例え話です

そのAPIは電話を受け取りました（API呼び出し）
あなたの話が分かったらAPIは担当者に仕事を依頼します
分からなかったら分かりませんとか出来ませんとか返事して電話を切ります（失敗し
た）
依頼したらあなたにいいよと返事して電話を切ります（API呼び出し完了）

でも依頼した仕事が戻ってくるまで、制御は返せないのでは？

たとえば

int 関数①(int 仕事の種類)
{
if(仕事の種類　できる）{
　　　関数②(仕事の種類)　//専門の担当者 関数②をよびだして処理させる
return 1; //仕事を受け付けた
}
else
return 0; //処理できなかった
}

int 関数②(int 仕事の種類)
{
仕事の処理・・・
return 1;
}

このばあい、依頼された専門家の関数②が処理を終えるまで、関数①は処理を返さない
と思うわけで・・・

マルチスレッドでしょう。

話が長くなりすぎるのでマルチスレッドの解説はしないよ。

>でも依頼した仕事が戻ってくるまで、制御は返せないのでは？

依頼するまでがAPIの役目だったら、依頼先の作業が終わるまでAPIが待つことはない
とは思いませんか？

>>API関数の中には呼び出し側にすぐに
>>制御を返してくるモノがありますよね
がどのAPIについてのことなのかわからないので敢えて例え話をしたわけですが
お気に召しませんでしたでしょうか？

考えている範疇がシングルプロセスのシングルスレッドで考えているから
そうなってしまうのだと思います。
wclrp ( 'o')さんが書かれているようにマルチスレッドを使うとか
マルチプロセスを使って処理をする場合であれば、今の考え方から
抜け出せるのではないかと思います。
言語がCであってもマルチプロセスやマルチスレッドは可能ですから
言われているような処理をしたいと思うのであれば、
マルチスレッドやマルチプロセスの勉強をされてはどうでしょう？

CPUもマルチコア化してますし、マルチスレッドの技術は今後どんどん
有効になっていくと思います。

マルチプロセスやマルチスレッドを利用しない場合ですが。
そういう条件下では実行ユニットは一つです。
概念的に並列化したりということがあっても、実行ユニットは一つです。
それを踏まえてですね。
ウインドウズはデータ構造であるQueueに処理を溜め込むように出来ています。
ウインドウズのメッセージループを思い出してください。
GetMessage
でキューから読み出して、
TranslateMessage
DispatchMessage
これらが適切にメッセージIDとパラメータを設定してWndProcを呼び出すことでイベント
トリブンは動作します。

そういう感じで
Queueをforで舐めるとかキューイングすると言う動作は実際にその場で処理するよりも軽
いことが多いと言うことです。
でもどこかでその本道の処理をしないことには貴方の目的を達成することが出来ません。
そして、貴方はやっているはずです。