attachment 9014219[details] works for me with the xpcshell-test.
However, I need some input since SyncLaunch on mainthread is not the perfect solution, though.
(SyncLaunch a process takes 270 ms in my computer, which is long)
AsyncLaunch (LaunchAndWaitForProcessHandle) version flow on the main process:
step1 Main Thread
- SocketProcessHost::Launch
- GeckoChildProcessHost::LaunchAndWaitForProcessHandle
step2 Non-Main Thread
- SocketProcessHost::OnChannelConnected
step3 Main Thread
- SocketProcessHost::InitAfterConnect
- PSocketProcessParent::Open // top-level ipdl open
- PSocketProcessParent::SendSetOffline
- OnProcessLaunchComplete
As you know, launch takes really long time.
Socket request highly possible occurs before step2.
Moreover, step3 looks like it must be in the main thread.
So we have two options:
(1) simply block the main thread if there's a socket request and we haven't finished the process launch.
(2) queues the requests. Once the |OnProcessLaunchComplete| fires, dispatch the requests in queue.
Although it did heavily block in xpcshell-test.
However, we don't block main thread for ./mach run.
Hence I prefer the simple implementation.

(In reply to Junior Hsu from comment #2)
> (2) queues the requests. Once the |OnProcessLaunchComplete| fires, dispatch
> the requests in queue.
This is the most acceptable solution, yes. I believe we will have more places accessing the gIOService->mSocketProcess in a potentially racy way, tho. We will simply have to catch and fix them all when they appear.
Main thread blocking (either to have some monitor signalling or spin the main thread even loop) is not an option.

(In reply to Dragana Damjanovic [:dragana] from comment #8)
> Junior, has this landed? can you land it? Can you also make a new bug and
> upload a patch that we can land on the m.-c. (without http2 part). Please
> make on top of 1513135
I believe it's bug 1513057. I'll post my patch there since all the patches should be land in one-shot.