|
From: Ivan B. <iv...@cs...> - 2006-05-08 19:32:43
|
Hi, I have a few questions concerning the bulk trasport api. My main question concerns the use of X_SOCKET rather than an integer fd like identifier for the socket. My problems with it are the following: 1. Possible unsafe\incorrect pointer passed to a vfer library function means we can't always bail gracefully and be very careful about locking anything for example before accessing the pointer. 2. User has to worry about deallocation of memory for this structure rather than let the lib handle the details of this. 3. Because the structure can't contain more than a stats structure and error status (wouldn't want the user to access/tweak internally maintained vars that might require a mutex lock before access), means that internally there will be another bigger structure to which X_SOCKET must have a reference, probably an fd-like equivalent. It would simplify things if we dealt with an fd. 4. Berkeley sockets api deals with fds, so it might be more transparent for users to use fds with VFER, even less work for them to translate existing code to use VFER. To handle errors, I can return a negative integer which will carry the error code that wouldn't have to be looked up with x_sockerror() and can be translated with errortext() as defined. My second question concerns the semantics of x_sockstats(). If the socket structure contains a stats structure, is that the outdated structure? Does this call update the socket's stats structure, and if so, why not return void and have the user access the stats structure using the X_SOCKET ptr? Also why is the return type a pointer, does this mean that the lib will allocate the memory for the stats structure and its up to the user to release it, perhaps returning a stats structure itself rather than a pointer would be better, as the user wouldn't have to deal with mem deallocation? thanks, ivan. |