|
|
Boost : |
From: Andrew Schweitzer (a.schweitzer.grps_at_[hidden])
Date: 2006-01-02 18:54:19
More notes/examples. Let me know if anything needs to be refined.
In particular, are there other examples that would be useful, off the
top of your head?
--------------Services on Windows-----------------
This is a complete (?) list of creatable on Windows NT 4.0 and above.
**Services are created at run-time when a user-level object (e.g. a
stream_socket) that needs them is created.
**Services in this list with the same name will be re-used if they
already exist. So, for example, if user creates a socket_acceptor then a
stream_socket, the socket_acceptor will add the win_iocp_socket_service
and the select_reactor<true> services, and then the stream_socket will
find and re-use them.
**The first item in each hierarchy is the user-level object whose
instantiation creates the hierarchy. The reset of the items are
services.
demuxer
demuxer_service
win_iocp_demuxer_service
stream_socket
stream_socket_service
win_iocp_socket_service
select_reactor<true>
datagram_socket
datagram_socket_service
win_iocp_socket_service
select_reactor<true>
acceptor_socket
socket_acceptor_service
win_iocp_socket_service
select_reactor<true>
deadline_timer
deadline_timer_service
reactive_deadline_timer_service
select_reactor<true>
locking_dispatcher
locking_dispatcher_service [with one set of template parameters]
locking_dispatcher_service [with another set of template
parameters] (??)
host_resolver
host_resolver_service [with one set of template parameters]
host_resolver_service [with another set of template parameters] (??)
ssl::context
context_service
openssl_context_service
ssl::stream
stream_service
openssl_stream_service
--------------Platform differences----------------
Platform: Uses:
linux 2.5.45 and above epoll
Mac kqueue
Windows NT 4.0 and above IoCompletionPort
Everything else select
In general specialized services look like this:
Layer Class
0 user-level object
1 asio-level service
2 general-concept-implementation service
3 platform-implementation service
In general specialized services look like this:
Layer Example class
0 stream_socket
1 stream_socket_service
2 reactive_socket_service
3 epoll_reactor
**For the demuxer_service and the socket services, WinNT 4.0 doesn't use
the general-concept-implementation service but intstead has it's own
"win_iocp-conecpt-implementation" classes.
**All three socket services share the same conecept-implementation and
platform-implementation-services.
**Not all services have platform-specific implementations.
locking_dispatcher, host_resolver and the ssl services context and
stream are the same on all platforms.
Comparison of specialized servives on Windows and Linux:
SHARED NT LINUX
0 demuxer
1 demuxer_service
2 win_iocp_demuxer_service task_demuxer_service
3 [none] epoll_reactor<false>
0 stream_socket
1 stream_socket_service
2 win_iocp_socket_service reactive_socket_service
3 select_reactor<true> epoll_reactor<false>
0 datagram_socket
1 datagram_socket_service
2 win_iocp_socket_service reactive_socket_service
3 select_reactor<true> epoll_reactor<false>
0 acceptor_socket
1 socket_acceptor_service
2 win_iocp_socket_service reactive_socket_service
3 select_reactor<true> epoll_reactor<false>
0 deadline_timer
1 deadline_timer_service
2 reactive_deadline_timer_service
3 select_reactor<true> epoll_reactor<false>
--------------------------Example------------------
Example of a Windows program using:
*asynchronous timer callbacks,
*asynchronous socket i/o,
*tcp and udp
*serving, via stream_socketasync_accept
*one demuxer shared between timer and socket code.
*no additional threads beyond main() and threads created by library.
In this example, the demuxer is created first (it has to be), then a
stream_socket is created, then an async_timer is created, finally
demuxer::run is called.
1) demuxer::demuxer() creates:
demuxer_service creates:
win_iocp_demuxer_service
The demuxer now has 2 services:
demuxer_service
win_iocp_demuxer_service
No additional threads are running.
The win_iocp_demuxer_service has allocated a Windows IoCompletionPort.
2) stream_socket::stream_socket(demuxer) creates:
stream_socket_service creates:
win_iocp_socket_service creates:
select_reactor<true> (a service)
The demuxer now has 5 services:
demuxer_service
win_iocp_demuxer_service
stream_socket_service
win_iocp_socket_service
select_reactor<true>
The select_reactor service has started a thread. The behavior of this
thread depends on whether any async winsock calls are made If
none are made the thread will call Sleep(till next timer expires);
otherwise it will call select(with timeout when next timer expires).
When this thread has nothing to do it will call select and wait to
be interrupted.
3) datagram_socket::datagram_socket(demuxer) creates:
datagram_socket_servivice finds already existing:
win_iocp_socket_service
The demuxer now has 6 services:
demuxer_service
win_iocp_demuxer_service
stream_socket_service
win_iocp_socket_service
select_reactor<true>
datagram_socket_service
4) acceptor_socket::acceptor_socket(demuxer) creates:
socket_acceptor_service finds already existing:
win_iocp_socket_service
The demuxer now has 7 services:
demuxer_service
win_iocp_demuxer_service
stream_socket_service
win_iocp_socket_service
select_reactor<true>
datagram_socket_service
socket_acceptor_service
5) deadline_timer::deadline_timer(demuxer) creates:
deadline_timer_service creates:
reactive_deadline_timer_service finds already existing:
select_reactor<true>
The demuxer now has 8 services:
demuxer_service
win_iocp_demuxer_service
stream_socket_service
win_iocp_socket_service
select_reactor<true>
deadline_timer_service
reactive_deadline_timer_service
No additional threads are running.
However, in order to use asynchronous callbacks, demuxer::run must
be called in some thread.
6) demuxer::run() is called in WinMain.
There are now two threads running:
select_reactor thread executes select_reactor which
loops on Sleep(till next timer expires)
main thread executes demuxer::run which loops on
GetQueuedCompletionStatus and executes completion
handlers.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk