RpcReader(3I)
π RpcReader(3I) π
okay bestie, so this is a page from the InterViews Reference Manual, and it's all about RpcReader β the little icon that reads RPC requests off a client π«Ά
β¨ NAME β¨
RpcReader β read RPC requests from a client π
β¨ SYNOPSIS β¨
#include <Dispatch/rpcreader.h>
πΈ DESCRIPTION πΈ
so like. an RpcReader reads RPC requests from an rpcstream, and that rpcstream is basically the ~connection~ to a client, right? when it reads an RPC request, it takes the request number, uses it to look up the address of a function in an array, and then calls that function to unmarshall the request's arguments and execute the request. it's giving dispatch energy. it's giving main character. β¨
An RpcReader is not instantiable β nope, not happening, you cannot just make one, sorry bestie π you have to implement a derived class. that derived class has to:
- initialize the function array with addresses of static member functions that unmarshall RPC requests, and
- define the action to be performed when the client closes the connection.
the function array looks like this, exactly like this, no notes:
typedef void (*PF)(RpcReader*, RpcHdr&, rpcstream&);
PF* _function;
every function you store in that array should:
- extract any arguments needed by the RPC request from the
rpcstream, - execute the RPC request, and
- insert any return values into the
rpcstreamso they can be sent back to the client π¦
π CONSTRUCTORS π
RpcReader(rpcstream* client, int nfcns)RpcReader(int fd, int nfcns, boolean binary = true)
β if you hand it a non-nil rpcstream, it gets ready to read RPC requests from the client using that stream. if you hand it a nil rpcstream, it just allocates the function array, that's it, that's the whole job π if you hand it a file descriptor, it creates a new rpcstream and gets ready to read RPC requests from the client using that. and nfcns? that sets the size of the function array that each constructor allocates. periodt. π
π PROTECTED OPERATIONS π
virtual int inputReady(int)β read an RPC request. and listen, it's only one request per call, on purpose, so the program can service RPC requests from multiple connections in round robin fashion π then it looks up the appropriate function in the reader's function array β or in another reader's function array β and calls it to handle the RPC request. it returns the appropriate status to tell theDispatcherwhether to detach theRpcReader, callinputReadyagain, or wait for new data before callinginputReadyagain. good news: a derived class should not need to redefine this function π«Άvirtual RpcReader* map(unsigned long reader)β you can redefine this one to change which reader executes an RPC request after it's read π ordinarily the same reader that reads an RPC request also executes it, but you're allowed to hand the request off to another reader too. sharing is caring.virtual void connectionClosed(int fd) = 0β you have to define this function π because it may be your only chance to perform cleanup (such as deletingthis) when the client closes the connection. no cap, do not skip this one.
π SEE ALSO π
RpcHdr(3I), RpcService(3I), rpcstream(3I)
and that's the whole vibe bestie, slay, go write that derived class πβ¨
this absolute banger of a manpage came to you courtesy of InterViews, dated 27 March 1991 β yes, iconic, we know, the vintage is part of the aesthetic ππ¦β
π¦ where this page comes from
- debian bookworm: ivtools-dev 2.0.11d.a1-1+b4
- debian trixie: ivtools-dev 2.0.11d.a1-3+b4
- ubuntu jammy: ivtools-dev 2.0.11d.a1-1build1
- ubuntu noble: ivtools-dev 2.0.11d.a1-3build1
- ubuntu questing: ivtools-dev 2.0.11d.a1-3build7
- ubuntu resolute: ivtools-dev 2.0.11d.a1-3build9
- ubuntu stonking: ivtools-dev 2.1.1+git.2025.07.26.a1-1 Β· MIT
- π girlified by deepseek-ai/DeepSeek-V4.1-Flash on : a language model's rewrite of the original, under its terms