As the subject says :-)
"It all started" with my app not working (what a surprise), and no
matter what, I couldn't find anything wrong with it. Originally I
thought is was because I'm using Debian, and that installed two
versions of libobjc that the linker warned me could conflict, so I
downloaded the current svn version just yesterday, eventually got
it to compile, and despite the linker warning being gone now it
still doesn't work.
Now, to the "it". I'm sending a NSPortMessage, containing one NSData,
via an NSSocketPort. It never arrives, or causes the receiver to spit
out messages about invalid data. Took me a while to figure out how
to connect two socket ports, but that part seemed to work.
Since I had the svn version anyway, I decided to waste some time with
this chaotic code and try to understand what it's doing. From the
looks of it, you are sending a header item followed by data items, so
I added a few printf() to see what's actually received. Turned out,
apparently, it never gets the last data item. If I send 3 NSData, I
receive 2 GSP_DATA, and then it probably waits for the 3rd to arrive.
Looking at what appears to be the sending code, I found this in
NSSocketPort.m:2384
/*
* Now insert item header information as required.
* Pack as many items into the initial data object as
possible, up to
* a maximum of NETBLOCK bytes. This is to try to get a single,
* efficient write operation if possible.
*/
for (i = 1; i < c; i++)
{
id o = [components objectAtIndex: i];
I'm not quite sure whether I'm seeing this right, but it appears that
this could be the source of the problem: a few lines earlier, an
additional
NSData it is inserted into the components array at index 0, so you
correctly start at index 1 here. Except that "c" is the item count
before
that new item is inserted, so this loop never hits the last item.
Unfortunately, the item count in the header includes the last one...
so the message is never received completely, and I can't just work
around this problem by adding a dummy item at the end (this does look
like a possible workaround, though --- adding a category for the final
send after that loop, and reducing the item count in the header by 1.
Still have to find out whether I can call the original implementation
of the method, though).
As a quick test, I replaced the "i < c" with "i < c+1" (which isn't a
fix, of course...) --- and what do you know, I suddenly receive my
message. Sending two messages (the app is still in an early stage...)
in a row seems to work as well, so apparently there are no sync
probblems introduced by the test hack.
So *maybe* you'll just need a flag to remember whether you've put that
additional item into the array, and add that to the c in the loop.
Which won't help me; apparently the debian version is (like always
with Debian) already way behind your svn version... and I don't really
have the time to wait 3 years for Debian to pick up a fix :-)
Christian
this isn't the first problem I run into,
it's just the first I tried to look into while trying to figure out
the
best way to work around it, or the documentation is even more terrible
than I thought so far since it gives no indication how to use this
properly... especially in this case, since the Cocoa NSSocketPort
has a
completely different API, so the generally far better Apple docs don't
work.