hmbdc
simplify-high-performance-messaging-programming
|
A Client represents a thread of execution/a task. The execution is managed by a Context. a Client object could participate in message dispatching as the receiver of specifed message types. More...
#include <Client.hpp>
Public Member Functions | |
char const * | hmbdcName () const |
return the name of thread that runs this client, override if necessary More... | |
std::tuple< char const *, int > | schedSpec () const |
an overrideable method. returns the schedule policy and priority, override if necessary priority is only used when policy is "SCHED_RR", or "SCHED_FIFO" More... | |
size_t | maxBatchMessageCount () const |
an overridable method. client receives events in batches and the max batch size is controllable when running in direct mode Context. Here is to specify the max size. More... | |
virtual void | messageDispatchingStartedCb (uint16_t threadSerialNumber) |
called before any messages got dispatched - only once More... | |
virtual void | stoppedCb (std::exception const &e) |
callback called when this Client is taken out of message dispatching More... | |
virtual bool | droppedCb () |
callback called after the Client is safely taken out of the Context More... | |
virtual void | invokedCb (size_t dispatched) |
this callback is called all the time (frequently) - the exact timing is after a batch of messages are dispatched. After this call returns, the previously dispatched message's addresses are no longer valid, which means if you cache the event addresses in the previous handleMessageCb()s, you cannot use those after the return of the next invokeCb function. More... | |
virtual | ~Client () |
trivial | |
void | stopped (std::exception const &e) noexcept |
the following are for internal use, don't change or override | |
Protected Member Functions | |
void | batchDone () |
the derived user's Client has the option to stop the current batch of event dispatching. More... | |
A Client represents a thread of execution/a task. The execution is managed by a Context. a Client object could participate in message dispatching as the receiver of specifed message types.
message is dispatched thru callbacks in the loose form of void handleMessageCb(Message const& m) or void handleMessageCb(Message& m). some callbacks have default implementations. however, all callbacks are overridable to provide desired effects; When running in a Context, all callbacks (*Cb methods) for a hmbdc Client instance are garanteed to be called from a single OS thread, ie. no 2 callabacks of an Client instance are called concurrently, so the Client programmer can assume a single thread programming model callback-wise. The above also holds true for timer firing callbacks when a concrete Client deriving from TimerManager that manages the timers
See in example hmbdc.cpp
CcClient | the concrete Client type |
typename | ... Messages message types that the Client interested if the type of JustBytes is declared, use a special callback see below |
is expected see ConsoleClient.hpp
There are 3 categories of Messages can be specified here regular, REQUEST, REPLY REQUEST, REPLY are for synchronous request reply messages, this is like remote procedure call (RPC) function except it is more powerful that it gives more flexible forms of RPC returning behavior - see requestReply() sendReply() in Context.hpp, and RequestReply.hpp for details
|
inlineprotected |
the derived user's Client has the option to stop the current batch of event dispatching.
for example, if the user's Client decides it has handled all interested messages and wants to skip the remaining messages within the CURRENT batch, call this within any callback functions. use with caution, only when it is absolutely certain that there is NO messages of ANY type the Client need to care are within the current batch.
|
inlinevirtual |
callback called after the Client is safely taken out of the Context
exception thrown here is ignored and return true is assumed
Reimplemented in hmbdc::app::tcpcast::send_detail::SendTransportEngine, hmbdc::app::udpcast::sendtransportengine_detail::SendTransportEngine, and hmbdc::app::netmap::sendtransportengine_detail::SendTransportEngine.
|
inline |
return the name of thread that runs this client, override if necessary
this only used when the Client is running in direct mode
|
inlinevirtual |
this callback is called all the time (frequently) - the exact timing is after a batch of messages are dispatched. After this call returns, the previously dispatched message's addresses are no longer valid, which means if you cache the event addresses in the previous handleMessageCb()s, you cannot use those after the return of the next invokeCb function.
you can collectively process the messages received/cached so far here, or do something needs to be done all the time like powering another message loop
dispatched | the number of messages dispatched since last invokedCb called |
Reimplemented in hmbdc::app::udpcast::recvtransportengine_detail::RecvTransportEngineImpl< OutputBuffer, MsgArbitrator >, hmbdc::app::netmap::RecvTransportEngine< OutBuffer, MsgArbitrator >, hmbdc::app::tcpcast::recvtransportengine_detail::RecvTransportEngine< OutputBuffer, MsgArbitrator >, hmbdc::app::udpcast::sendtransportengine_detail::SendTransportEngine, hmbdc::app::tcpcast::send_detail::SendTransportEngine, hmbdc::app::utils::netperf_detail::SenderClient, hmbdc::app::netmap::sendtransportengine_detail::SendTransportEngine, hmbdc::app::utils::pingpong_detail::Pinger< Sender >, and hmbdc::app::StuckClientPurger< Buffer >.
|
inline |
an overridable method. client receives events in batches and the max batch size is controllable when running in direct mode Context. Here is to specify the max size.
a message could only be reaching one client when using partition Context. In this case, reduce the size (reduce the greediness) might be useful
|
inlinevirtual |
called before any messages got dispatched - only once
this is the place some preparation code goes to
threadSerialNumber | normally the number indicating which thread is in action, except when INTERESTS_SIZE == 0 it is another undefined value |
Reimplemented in hmbdc::app::udpcast::recvtransportengine_detail::RecvTransportEngineImpl< OutputBuffer, MsgArbitrator >, hmbdc::app::netmap::RecvTransportEngine< OutBuffer, MsgArbitrator >, hmbdc::app::udpcast::sendtransportengine_detail::SendTransportEngine, hmbdc::app::tcpcast::recvtransportengine_detail::RecvTransportEngine< OutputBuffer, MsgArbitrator >, hmbdc::app::tcpcast::send_detail::SendTransportEngine, hmbdc::app::utils::pingpong_detail::Ponger< Sender >, hmbdc::app::netmap::sendtransportengine_detail::SendTransportEngine, and hmbdc::app::utils::pingpong_detail::Pinger< Sender >.
|
inline |
an overrideable method. returns the schedule policy and priority, override if necessary priority is only used when policy is "SCHED_RR", or "SCHED_FIFO"
this is only used when the Client is running in direct mode supported policy are "SCHED_OTHER"(=nullptr), "SCHED_RR", "SCHED_FIFO"
|
inlinevirtual |
callback called when this Client is taken out of message dispatching
after this call the Client is still at hook from the Context point of view (until droppedCb is called), so don't delete this Client yet or add it back to the Context. any exception thrown here is ignored,
e | the exception that caused the Client to be taken out of message dispatching e could be thrown by the Client itself in a callback function to voluntarily take itself out |
Reimplemented in hmbdc::app::udpcast::recvtransportengine_detail::RecvTransportEngineImpl< OutputBuffer, MsgArbitrator >, hmbdc::app::netmap::RecvTransportEngine< OutBuffer, MsgArbitrator >, hmbdc::app::utils::netperf_detail::ReceiverClient, hmbdc::app::tcpcast::recvtransportengine_detail::RecvTransportEngine< OutputBuffer, MsgArbitrator >, hmbdc::app::utils::netperf_detail::SenderClient, hmbdc::app::utils::pingpong_detail::Ponger< Sender >, hmbdc::app::netmap::sendtransportengine_detail::SendTransportEngine, hmbdc::app::utils::pingpong_detail::Pinger< Sender >, and hmbdc::app::StuckClientPurger< Buffer >.