Re: CFMessagePortSendRequest seems to ignore sendTimeout
Re: CFMessagePortSendRequest seems to ignore sendTimeout
- Subject: Re: CFMessagePortSendRequest seems to ignore sendTimeout
- From: Stéphane Sudre <email@hidden>
- Date: Sun, 13 Mar 2005 23:55:38 +0100
On dimanche, mars 13, 2005, at 11:11 PM, David Niemeijer wrote:
At 22:37 +0100 13/3/05, Stéphane Sudre wrote:
On dimanche, mars 13, 2005, at 10:31 PM, David Niemeijer wrote:
Does anyone here have experience with timeouts and
CFMessagePortSendRequest? As far as I understand CFTimeInterval is
in seconds, so if I pass 0.02 for sendTimeout when calling
CFMessagePortSendRequest I would expect a kCFMessagePortSendTimeout
error if more than 0.02 secs are needed. However, what I am seeing
is that CFMessagePortSendRequest can take for example 6 ticks (= 0.1
sec) and still return with noErr, so not timing out as I would have
hoped. Am I doing something wrong, is the documentation incorrect,
or is this a bug? I am running on 10.3.8 and calling it like this:
result = CFMessagePortSendRequest( sMessagePort, inMessageID,
inData, 0.02, 0, NULL, &replyData ) ;
Note that I am not interested in getting a reply.
A related question:
What kind of things influence the duration of this call. To what
degree does what happens at the receiving end influence the duration
of the call. I am not working with return values so I am presuming
that as soon as the CFMessagePortCallBack at the receiving end is
called CFMessagePortSendRequest is able to return and not delayed by
any processing inside the callback, is this a correct assumption?
Shouldn't you use
result = CFMessagePortSendRequest( sMessagePort, inMessageID, inData,
0.02, 0, kCFRunLoopDefaultMode, NULL ) ;
if you don't want to deal with the return value and return as soon as
the message is sent?
/* NULL replyMode argument means no return value expected, dont wait
for it */
Maybe, but this is what I found in the online docs:
replyMode
The run loop mode in which the function should wait for a reply. Pass
NULL if you do not want or expect a reply.
returnData
On return, a pointer to a CFData containing the reply data. You are
responsible for releasing the data.
Which suggests that I may pass NULL to the second last parameter (if I
don't want a reply) and does not tell me whether NULL is allowed for
the last one. But perhaps I misread this or perhaps the docs are wrong
or incomplete.
The documentation is correct and you are too.
I had a look at the CFMessagePortSendRequest source code and the
time-out is used for the mach_msg call. So the time-out does not apply
to the whole CFMessagePortSendRequest code and there does not seem to
be any atomic restrictions in the code which would prevent other
processes to take CPU time during the execution of this method till the
call to mach_msg. Not sure it would explain the situation.
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Darwin-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden