MySQL 5.6.14 Source Code Document
 All Classes Namespaces Files Functions Variables Typedefs Enumerations Enumerator Friends Macros Groups Pages
trp_callback Struct Reference
Inheritance diagram for trp_callback:
Collaboration diagram for trp_callback:

Public Member Functions

int checkJobBuffer ()
void reportSendLen (NodeId nodeId, Uint32 count, Uint64 bytes)
void lock_transporter (NodeId node)
void unlock_transporter (NodeId node)
Uint32 get_bytes_to_send_iovec (NodeId node, struct iovec *dst, Uint32 max)
Uint32 bytes_sent (NodeId node, Uint32 bytes)
bool has_data_to_send (NodeId node)
void reset_send_buffer (NodeId node, bool should_be_empty)
- Public Member Functions inherited from TransporterCallbackKernel
void deliver_signal (SignalHeader *const header, Uint8 prio, Uint32 *const signalData, LinearSectionPtr ptr[3])
void reportReceiveLen (NodeId nodeId, Uint32 count, Uint64 bytes)
void reportConnect (NodeId nodeId)
void reportDisconnect (NodeId nodeId, Uint32 errNo)
void reportError (NodeId nodeId, TransporterError errorCode, const char *info=0)
void transporter_recv_from (NodeId node)

Detailed Description

Definition at line 921 of file mt.cpp.

Member Function Documentation

Uint32 trp_callback::bytes_sent ( NodeId  node,
Uint32  bytes 
)
virtual

Called when data has been sent, allowing to free / reuse the space. Passes number of bytes sent.

Note that this may be less than the sum of all iovec::iov_len supplied (in case of partial send). In particular, one iovec entry may have been partially sent, and may not be freed until another call to bytes_sent() which covers the rest of its data.

Returns total amount of unsent data in send buffers for this node.

Like get_bytes_to_send_iovec(), this is called during performSend().

Implements TransporterCallback.

Definition at line 1914 of file mt.cpp.

Here is the caller graph for this function:

int trp_callback::checkJobBuffer ( )
virtual

This method is called regularly (currently after receive from each transporter) by the transporter code.

It provides an opportunity for the upper layer to interleave signal handling with signal reception, if so desired, so as to not needlessly overflow the received signals job buffers. Ie. the single-threaded kernel implementation currently executes received signals if the job buffer reaches a certain percentage of occupancy.

The method should return non-zero if signals were execute, zero if not.

theoretically (or when we do single threaded by using ndbmtd with all in same thread) we should execute signals here...to prevent dead-lock, but...with current ndbmtd only CMVMI runs in this thread, and other thread is waiting for CMVMI except for QMGR open/close connection, but that is not (i think) sufficient to create a deadlock

FIXME: On a CMT chip where #CPU >= #NDB-threads sched_yield() is effectively a NOOP as there will normally be an idle CPU available to immediately resume thread execution. On a Niagara chip this may severely impact performance as the CPUs are virtualized by timemultiplexing the physical core. The thread should really be 'parked' on a condition to free its execution resources.

Implements TransporterCallback.

Definition at line 1684 of file mt.cpp.

Uint32 trp_callback::get_bytes_to_send_iovec ( NodeId  ,
struct iovec dst,
Uint32   
)
virtual

ToDo: In current patch, these are not used, instead we use default implementations in TransporterRegistry. Ask upper layer to supply a list of struct iovec's with data to send to a node.

The call should fill in data from all threads (if any).

The call will write at most MAX iovec structures starting at DST.

Returns number of entries filled-in on success, -1 on error.

Will be called from the thread that does performSend(), so multi-threaded use cases must be prepared for that and do any necessary locking.

Process linked-list and put into iovecs TODO: Here we would also pack stuff to get better utilization

Implements TransporterCallback.

Definition at line 1804 of file mt.cpp.

Here is the caller graph for this function:

bool trp_callback::has_data_to_send ( NodeId  node)
virtual

Called to check if any data is available for sending with doSend().

Like get_bytes_to_send_iovec(), this is called during performSend().

Implements TransporterCallback.

Definition at line 1924 of file mt.cpp.

void trp_callback::lock_transporter ( NodeId  node)
virtual

To lock during connect/disconnect, we take both the send lock for the node (to protect performSend(), and the global receive lock (to protect performReceive()). By having two locks, we avoid contention between the common send and receive operations.

We can have contention between connect/disconnect of one transporter and receive for the others. But the transporter code should try to keep this lock only briefly, ie. only to set state to DISCONNECTING / socket fd to NDB_INVALID_SOCKET, not for the actual close() syscall.

Note: take the send lock first, so that we will not hold the receive lock while blocking on the send lock.

The reverse case, blocking send lock for one transporter while waiting for receive lock, is not a problem, as the transporter being blocked is in any case disconnecting/connecting at this point in time, and sends are non-waiting (so we will not block sending on other transporters).

Reimplemented from TransporterCallback.

Definition at line 1659 of file mt.cpp.

void trp_callback::reportSendLen ( NodeId  nodeId,
Uint32  count,
Uint64  bytes 
)
virtual

The transporter periodically calls this method, indicating the number of sends done to one NodeId, as well as total bytes sent.

For multithreaded cases, this is only called while the send lock for the given node is held.

Implements TransporterCallback.

Definition at line 1629 of file mt.cpp.

void trp_callback::reset_send_buffer ( NodeId  node,
bool  should_be_empty 
)
virtual

Called to completely empty the send buffer for a node (ie. disconnect).

Can be called to check that no one has written to the sendbuffer since it was reset last time by using the "should_be_emtpy" flag

Implements TransporterCallback.

Definition at line 1941 of file mt.cpp.

Here is the call graph for this function:


The documentation for this struct was generated from the following file: