thread protocol modifiers

FROM : William Zumwalt
DATE : Sat Jan 05 02:06:58 2008

I've been trying to chase down a problem with my thread for sometime
and I think
I've found the problem with why I can't click on my interface even though I
have a thread processing my data in the background ... so I have a few
questions about protocol modifiers which I'm looking at as the culprit.


#1) I have a class method written 3 times. Once in the class @interface,
once as a @protocol method in the same file, and once in the implementation
file when defining the method.


I couldn't find this in the docs so my question is, when declaring a
protocol modifier, must they all three say (oneway void) to be valid or does
one of them override them all? I don't understand it, but it seems to me the
@interface declaration is useless other than suppress a few warnings and
make the class blueprint easier to read. Maybe someone can correct me on
that. I think I had to put it in all three places for this to work, but I'm
not sure if that's correct.


#2) I make 3 calls to my server thread in sequence, so I marked all 3 as
(oneway void). After doing this I was able to click on a button in my GUI
while the thread was running, so I think the GUI was blocking w/ the default
(inout void) ... at least I think that's the default.


However my problem now is that with all three marked as (oneway void)
(sending async msgs), message #2 requires a few seconds to complete while
message #3 depends on message #2 before it can start, yet msg #3 is done
before msg #2 can finish. I've also seen once where they arrived out of
order.


// from the client

[server sendMsg1];

[server sendMsg2];

[server sendMsg3];


Is there another way to call asynchronously, yet guarantee that the messages
arrive in order? Or someway to call w/o the GUI blocking for a server
message return?