Re: wow, this actually works!
Re: wow, this actually works!
- Subject: Re: wow, this actually works!
- From: Bill Stewart <email@hidden>
- Date: Wed, 29 May 2002 11:34:49 -0700
on 29/5/02 5:14 AM, Kenneth Welch wrote:
>
> Then - at the botttow of the while loop put your thread into the wait
>
> state
>
> and forget about it - you should be fine from then on, as you're app has
>
> signed into CoreMIDI (with getting caught up by java's run loop mess)...
>
>
>
> I don't think you need to make every call into CM from this thread...
>
>
>
> Then you should be able to just do your stuff in your normal threads
>
>
Actually, my experience has been that any and every call that is either
>
MIDISetup.RestartMIDISystem, getDevice, getEntity, getDestination,
>
getNumberOfSources, getNumberOfDestinations -- basically anything that
>
has to query the hardware -- needs to be run from the separate thread
>
every time you want to use it. Whereas .send(packetlist) and so on
>
always work fine from the app's normal threads regardless. But even if
>
you need to run those hardware-related commands at times other than on
>
app launch, you'll still be able to get the while loop going again with
>
a notify() at the right time, whereas with an embedded sleep() as I
>
suggested earlier you'd have to wait for the current sleep() to finish
>
first. My apologies; wait() is in java.lang.Object not java.lang.Thread
>
so I didn't notice it was an available command. ;-)
>
>
Though I assume the wake-up variance in us/ms is equally bad when
>
calling notify on a waiting thread, as opposed to when it's waking up on
>
its own from a self-imposed sleep... any thoughts Kurt? Hehe.
The reason why you need to make all of these calls from this other thread is
BECAUSE you need to get notifications through a CFRunLoop from the MIDI
Server (and Java is messing with that run loop). Basically, by doing these
in a thread that Java UI is not seeing, I presume that these are succeeding
because its run loop isn't getting smashed like your other Java threads are
- I guess because the only thing you're doing in that thread is making calls
to CoreMIDI
>
>
> My comments were trying to clear up the previous comments that you could
>
> just do this stuff then let the thread exit - that won't work, because
>
> CoreMIDI will have lost its run loop to call you back on when it needs
>
> to...
>
>
Yep. Unless you're like me and your app never needs to receive any
>
callbacks from CoreMIDI. But with a wait() command there's no longer any
>
advantage to letting it run once and die each time, and there's also the
>
thread creation latency Pete mentioned earlier (though I don't know how
>
significant it is), so the loop seems completely preferrable at this
>
point...
Wait->Notify is preferable to have the thread created then die, or spinning.
There is not a lot of overhead in this - most threads in the OS go through
some kind wait->notify type loop fairly frequently - the whole event
mechanism on X (and Java) is delivered through wait->notify, etc....
It has tremendous advantages over either spinning or create/destroy
semantics, which is why it is use pervasively
Bill
>
_______________________________________________
>
coreaudio-api mailing list | email@hidden
>
Help/Unsubscribe/Archives:
>
http://www.lists.apple.com/mailman/listinfo/coreaudio-api
>
Do not post admin requests to the list. They will be ignored.
mailto:email@hidden
tel: +1 408 974 4056
__________________________________________________________________________
"Thousands of years ago, cats were worshipped as gods. We have never
forgotten this."
__________________________________________________________________________
_______________________________________________
coreaudio-api mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/coreaudio-api
Do not post admin requests to the list. They will be ignored.