Hi again,
In the following bit of code, I set the message size field of a message.
If they are internally moved among ports by only relinking the message
node, is this size relevant? I'm sure it would be if we had message
allocation and/or pool management backend for them, but we allocate them
ourselves in the user code... So is this field used for anything? Or is it
only there to possibly permit the library user to perhaps detect the type
of message it was sent by it's size? (Which it could do using other
methods as well... since the thread/task receiving a message is supposed
to know the expected types aleready, as a general rule, which optionally
could comport a user size field)...
Like in this code, the receiver of the message already knows it's size and
won't need to consult the field; Is it safe to not define the size then
(for future implementations as well)? Or should I still do it because Pth
may require it eventually? If it is the case perhaps a function or macro
could be provided to initialize messages so that internal structures do
not have to be modified by the user and API remain consistent among
revisions eg:
void pth_message_init(pth_message_t *, pth_msgport_t, unsigned int, void *);
It would not matter if it was called multiple times on the same message,
it would not clear the message but only reset the size, replyport and
data fields to requested values (which of course can be NULL for
replyport and data)
Or, an API similar to POSIX provides in some circumstances
int pth_message_setattr(pth_message_t *, int, void *);
int pth_message_getattr(void *, pth_message_t *, int);
where int could be MESG_RPORT, MESG_SIZE, MESG_DATA
Alternatively, if the structure will not change among revisions, it could
simply be specified in the man page and publically be exported in it
static bool
start_transfer_thread(clientenv *clenv)
{
/* XXX Which fits best for all future Pth implementations?
* clenv->tmsg.msg.m_size = sizeof(transfermsg);
* clenv->tmsg.msg.m_replyport = clenv->rport;
* clenv->tmsg.msg.m_data = NULL;
*/
/* ||
* pth_message_setattr(&(clenv->tmsg.msg), PTH_MSGATTR_RPORT,
* clenv->rport);
*/
/* ||
* pth_message_init(&(clenv->tmsg.msg), clenv->rport,
* sizeof(transfermsg), NULL);
*/
if ((clenv->tthread = pth_spawn(tthreadattr, (void *)transferthread,
clenv))) {
if (transfer_request(REQ_NONE, TRUE, clenv)) return (TRUE);
pth_join(clenv->tthread, NULL);
}
return (FALSE);
}
Hmm also, is there any useage of the data * field in the message
structure or is it left to the user to optionally allow opaque messages?
My message was defined similarly to on AmigaOS, where the pth_message_t
structure only provides the message linking node:
typedef struct transfermsg {
pth_message_t msg; /* Internal message node */
int request; /* Request to send to device */
bool result; /* Result status after device request */
int64_t rbytes, wbytes; /* Number of bytes transfered */
int64_t dlfiles, ulfiles; /* Number of files transfered */
int port; /* PORT or PASV port for next transfer*/
int file; /* File descriptor to read/write from/to*/
int rrate, wrate; /* Transfer dl/ul rate */
char *ipaddr; /* If PORT, address to connect to */
char *path; /* Path to be passed to ls() if list=TRUE*/
bool passive; /* Either next xfer is PORT or PASV mode*/
bool ongoing; /* TRUE when a transfer is in progress*/
char list; /* 0=File xfer, 1=LIST, 2=NLST, 3=empty*/
} transfermsg;
The way I see it, it appears possible with the size and data fields to
process opaque messages. If this is a useful feature, the message
initialization function seems a good idea... It may be useful to add
some notes in the man page as well to clarify this point so that users
don't need to temper internal Pth structures which theoretically could
eventually change in a future implementation. If it will not, the
pth_message_t structure contents could be shown in the man page under
the message ports section, clarifying that it is always safe to
user-set these fields among various Pth revisions...
If the goal is to allow opaque messages, perhaps that a type field
could be introduced (since message size is usually useful but
not appropriate to evaluate a message type).
Thanks again,
Matt
______________________________________________________________________
GNU Portable Threads (Pth) http://www.gnu.org/software/pth/
User Support Mailing List [EMAIL PROTECTED]
Automated List Manager (Majordomo) [EMAIL PROTECTED]
