djgroen / mpwide Goto Github PK

The status of C ::send and ::recv is read as an int, but if the buffer size is larger than that, it will deduce there is an error when there is not. In pseudo-code:

char *buf, long long int size;
int status = ::send(buf, size);
if (status < 0)
   report_error();

However, if size is larger than MAX_INT and this is successfully returned by ::send, status will be smaller than zero through casting.

I think its reasonable to assume that the input size should be an int, or that ::send will always return less than MAX_INT, but maybe an explicit comment about these assumptions would be good.

When cout is called in multiple threads it is possible that its internal data structures are corrupted. It seems to have been solved in C++11 ( http://stackoverflow.com/a/6374525/574082 ). Locally I'm compiling against C++98/C++03 to keep compatibility with older versions of GCC.

If MPW_ConnectPath(pathId, false) would timeout, it would be easier to handle exceptions with connecting

After a connect has failed and you try to free the resources you get a segmentation fault in DestroyPath->EraseStream if the path had multiple streams. I think the problem is that DestroyPath doesn't take into account that the stream numbers will change after calling EraseStream.

I'll try to write a patch ASAP.

This would allow error checking by the calling application. Just returning -1 is usually enough. I think a ::recv status of 0 should also be considered an error if it was successfully ::select-ed. From the recv() man page

 RETURN VALUES
 These calls return the number of bytes received, or -1 if an error
 occurred.

 For TCP sockets, the return value 0 means the peer has closed its half
 side of the connection.

Possible trouble:
Segmentation fault in reading a vector in SendRecv while it is being resized.

Possible solution:
Turn vector data structures that are modified in AddStreams into arrays. This way the arrays do have to be allocated when MPWide is started (compiled), but it saves a load of trouble because they are then immutable. It is then up to users to set a sensible maximum number of streams to be used within a single session.

Why is this, and how can we solve it?