Crunch CRiSP File Editor 6 - Manual (Page 81)

Page 81
The key to writing non-blocking macros is to write them based on callbacks, using the ipc_register() function.
There are four conditions for which you can register a callback:
IPC_TRIGGER_READ IPC_TRIGGER_READ
indicates data is a available to be read. You can successfully call ipc_read() once to read data. If
you attempt to call ipc_read() more than once within a callback you may block if the no data is
available.
If you back a zero length string then the connection has been disconnected by the remote end.
IPC_TRIGGER_WRITE IPC_TRIGGER_WRITE
indicates you can write data down a connection in a non-blocking manner. Normally you would not
need to worry about this condition, but if you plan to send large amounts of data then you may
need to take this into account to avoid causing CRiSP to hang on an ipc_write() function call.
When the callback is invoked you can call ipc_write(). You are advised to use the
IPC_NON_BLOCKING flag on the call to ipc_create() to ensure that the ipc_write() does not block.
If you are attempting to send too much data then the ipc_write() call will return a value less than the
lentgh of the data you are sending.
IPC_TRIGGER_EXCEPTION IPC_TRIGGER_EXCEPTION
This trigger is not guaranteed to have meaningful semantics for all the IPC communications
mechanisms, and is designed mainly for the TCP protocol.
IPC_PROCESS_DEATH IPC_TRIGGER_PROCESS_DEATH
This trigger is called for the IPC_ANON_PIPE and IPC_NAMED_PIPE IPC mechanisms. It is used
to indicate that the child process has terminated. You can usually ignore this callback since you can
detect the end of a communications session by having an IPC_TRIGGER_READ callback invoke
and attempt to read from the IPC connection. A zero length return from ipc_read() most likely
indicates the session has terminated.
IPC_ANON_PIPEIPC_NAMED_PIPE
When using the registered macro callbacks, you should set up the callback as soon as possible after
creating the IPC connection. If you attempt to set it up after the current macro has returned, then you may
miss a callback condition. This will happen if your macro terminates and CRiSP goes back to it's internal
main loop to read keyboard or mouse input.
{button See Also, ALink(ipc,,,)}
TCP/UDP Communications
When using TCP or the UDP protocol, you can create a client or a server connection end point. The most
common type is a client end-point. In the client scenario, CRiSP will connect to some service on the
network, for instance an HTTP WEB server. A server is the thing which provides a service, e.g. a printer
server, WEB server, FTP server.
IPC_TCPIPC_UDPTCP/UDP programming
You can create both types of connections. To create a TCP connection you use the ipc_create function. The
format is:
int ipc_id = ipc_create(IPC_TCP, "host:port");
int ipc_id = ipc_create(IPC_UDP, "host:port");
The second parameter to the ipc_create() primitive is the name and port number of the service. The name
field can be a standard hostname, e.g. crisp.demon.co.uk, or an IP address in standard notation (e.g.
192,80,255.255). The port number is a standard TCP or UDP port number or service name. E.g. the
following are valid names:
crisp.demon.co.uk:ftp
crisp.demon.co.uk:23
192.8.99.99:23
If you are creating a server application then you should omit the hostname and separating colon. For
example
int ipc_id = ipc_create(IPC_TCP, "ftp");
The above example would create a TCP connection service which listens on FTP port number.