AsioExternalThreadEvent::unserialize() may legally throw PHP exceptions.
When that happens, construction of PHP exceptions reenters VM, surprised
flag is checked and pending C++ exceptions may be thrown.
Let's make sure the queue of received events in runUntil() is not lost.
Move this responsibility to the AsioExternalThreadEventQueue.
External thread event queueing logic is big enough that it deserves its
own class. Move the code and rename members to better reflect the
underlying operations. Implementation is otherwise unchanged.
Destructor of AsioExternalThreadEvent uses assert() to check whether the
state is legal. Introduction of abandon() mechanism makes it possible to
destroy the AsioExternalThreadEvent in the Waiting state and hit the
assertion error.
This diff solves the problem by introducing Abandoned state.
I was learning from @jdelong and he said that you should use
double quotes for local includes and angle brackets for library
includes. I asked why our code was the way it was, and he said he wanted
to clean it up. I beat him to it :)
Conflicts:
hphp/runtime/base/server/admin_request_handler.cpp
hphp/runtime/vm/named_entity.h
Sometimes, a PHP object (usually defined by extension) is needed to
unserialize the data.
Provide a safe mechanism to store such object with external thread
events.
Add support for external thread events.
See asio_external_thread_event.h for details about usage.
This is the first version that compiled, the code was not executed even
once, but wanted to get it out early to unblock @hannesr. Thus the [RFC]
flag.
My next step is to implement asio-compatible equivalent of
fb_call_user_func_async() that will make it possible to easily test the
new functonality by simulating async stuff with sleep(), etc. on the PHP
side.
There are 2 major mostly lockless synchronization points that needs
careful review:
- queue of ready external thread events (asio_session.{cpp.h})
- shutdown cleanup (asio_external_thread_event.{cpp,h})
Jan Oravec