Re: Problem with AESend()
Re: Problem with AESend()
- Subject: Re: Problem with AESend()
- From: "Patrick M" <email@hidden>
- Date: Thu, 12 Apr 2007 10:03:43 -0400
Unfortunately, thread safety is not the problem that I am running into, and
as for the 'why' I can't really answer that because I came onto the project
after most of this was written.
From what I can surmise though, additional timer firings will not happen
until the current callback completes, and if the current callback never
completes, the timer never fires again and my main message loop is locked
up.
I guess my real question is why the AESend function waits forever when the
message CANNOT be sent? Surely this is a detectable error? This sounds
like a bug to me... Without this behaviour it is impossible to guarantee
proper execution using Apple Events. What good is it to send a message and
have the function sit there becuase it doesn't know what is going on, a
definitive response is required. It is not actually waiting for something
to happen, nothing could possibly happen to kick it out of the infinite
wait. What is it waiting for now that the message failed to send?
On 4/12/07, Philip Aker <email@hidden> wrote:
On 2007-04-11, at 14:39:29, Patrick M wrote:
> Hi, I have a problem using (correctly apparently) Apple Events.
> The scenario:
> I have an application (which we will call AppA) that does 'stuff'.
> I also have a menu bar item (that lives in SystemUIServer... which
> we will call AppB) that polls AppA for it's status using Apple
> Events (AESend, infinite timeout, waiting for reply) and displays
> it with a fancy icon.
> I have seen some threads on AESend blocking for certain things, but
> nothing conclusive with respect to my situation.
> Before anyone tells me a better way to do this, I already know,
> unfortunately I am unable to do it properly, i need to work with
> what i have.
> AppB uses a timer to poll AppA, once every second. If AppA is
> busy, say processing an event to open a document (which AppA does
> indeed do), the next time AppB sends AppA a message, while AppA is
> still processing the event to open a document, it hangs. Also,
> once AppA is done opening the document, I had assumed that the
> message AppB sent was queued and would get to the front of the
> queue in time, but it seems to never do that. Even after AppA
> becomes idle, AppB continues to hang on AESend, no error is
> returned!!!!!!!!
> I have heard that the queue size is set at 5, and that means things
> pile up really fast, but if that is the case, why would the message
> sent from AppB not fail at some point (note i have used the wait
> forever option)? if it is in the queue, it should get to it
> eventually, and if the queue was full when it tried, why is an
> error not returned?
> I _have_ been able to get around all this implementing my own queue
> of events (with threads waiting on one semaphore) , but this seems
> dumb since the OS should be doing this for me. I don't want to
> reimplement the event queue.
> I would like a definitive answer as to why AppB hangs as it does
> and what can i do within the guidelines of AESend to not hang when
> the receiving process is busy.
> Someone asked about increasing the queue size, but no one
> answered. Is this possible? Really one would expect AESend to
> return with an error if the queue is full, why is this not so?
> also, any other documentation about the queue behaviour/size would
> be appreciated.
There's a new example at: <http://developer.apple.com/samplecode/
AESendThreadSafe/index.html>. Maybe it can be of some use? I'm a big
AppleEvent fan but in this case (having read your plea for no
advice), perhaps it might be more expedient to set up a notification
method from AppA to AppB which posts the status changes and forget
all about timers, timeouts, and queues. Otherwise, I find the
described approach kinda confusing -- like why are you sending a
message with wait forever every second? To me that means that if AppA
is busy, then the intended reply receiver in AppB will be destroyed
before AppA can return.
Philip Aker
email@hidden
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Carbon-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden
_______________________________________________
Cocoa-dev mailing list (email@hidden)
Do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden