From: Christopher Kohlhoff (chris_at_[hidden])
Date: 2005-12-18 00:27:31
--- simon meiklejohn <simon_at_[hidden]> wrote:
> The one other degenerate case i guess is if post or dispatch
> are called from a foreground thread and no thread ever calls
> demuxer::run, then the handler simply wont be called.
Yep, it will also leak objects on some platforms.
> One final concern i had is about use of asio in multiple static
> libs linked into a final application. (An example that would
> come up in my work in VOIP would be separate libs
> for media streaming using udp/rtp, SIP protocol using
> tcp or udp, application networking on tcp, logging
> to file etc)
> Are there issues with this setup? Would there end up
> being some per lib static objects/threads, or could i
> call demuxer::run from a single point in the app and have
> it service i/o throughout the app? I probably should be
> able to figure this out from the source, but when i drill
> down through the code the answer eludes me.
If these are static libraries then I believe the linker will
coalesce the symbols so that you only end up with one copy of
each. I.e. linking static libs isn't really any different to
linking object files, as I understand it.
In general, most resources in asio, like threads, hang off a
demuxer in some way, rather than being static variables.
However, sharing a single demuxer across the application also
sounds like a viable design to me. Although this maybe does not
apply in your case, it's a design approach that lets you combine
independent modules into a program that has only one thread.