Go to the source code of this file.
◆ DECLARE_SERVE_SERIALISER
#define DECLARE_SERVE_SERIALISER |
( |
| T | ) |
|
Value: struct ServeProto::Serialise< T > \
{ \
static T read(
const StoreDirConfig &
store, ServeProto::ReadConn conn); \
static void write(
const StoreDirConfig &
store, ServeProto::WriteConn conn,
const T &
t); \
};
ChunkedVector< std::string, 8192 > store
Definition lexer.l:1011
T t
Definition lexer.l:154
Declare a canonical serialiser pair for the worker protocol.
We specialise the struct merely to indicate that we are implementing the function for the given type.
Some sort of template<...>
must be used with the caller for this to be legal specialization syntax. See below for what that looks like in practice.
◆ GET_PROTOCOL_MAJOR
#define GET_PROTOCOL_MAJOR |
( |
| x | ) |
|
Value:
T x
Definition lexer.l:2648
◆ GET_PROTOCOL_MINOR
#define GET_PROTOCOL_MINOR |
( |
| x | ) |
|
◆ operator<<() [1/2]
Sink & nix::operator<< |
( |
Sink & | sink, |
|
|
ServeProto::Command | op ) |
|
inline |
Convenience for sending operation codes.
- Todo
- Switch to using
ServeProto::Serialize
instead probably. But this was not done at this time so there would be less churn.
◆ operator<<() [2/2]
std::ostream & nix::operator<< |
( |
std::ostream & | s, |
|
|
ServeProto::Command | op ) |
|
inline |
Convenience for debugging.
- Todo
- Perhaps render known opcodes more nicely.