[EMAIL PROTECTED] wrote:
> I still don't know which error you're getting, but I think that TimSetSeconds
> (in PalmOS3.5) actually broadcasts a _deferred_ notification. This means the
> notification isn't broadcast (and thus, the stack isn't checked) until the next
> time you call EvtGetEvent().
Here's the stack trace of a TimSetSeconds that complained:
0000C50C #0000003022 10C844BE TimSetSeconds+00A4
0000C4E0 #0000000044 10C84920 PrvBroadcastTimeChange+0028
0000C4C2 #0000000030 10C454DE SysNotifyBroadcast+0114
0000C486 #0000000060 10C457A0 PrvBroadcastNotification+0014
i.e. things do not appear to be deferred for TimSetSeconds. Besides which, I rely on
the order of receiving notifications i.e. the
time notification and then one of my own sent out afterwards via SysAppLaunch. If you
changed the order of this mechanism then my
code would have been stuffed.
Fortunately, it appears that you have preserved the order of things for TimSetSeconds.
> > Unfortunately PalmOS isn't very good about guaranteeing
> > stack space to notification handlers. In fact, it doesn't
> > do anything about this at all.
>
> Actually, this is not true. I missed the original message that started this
> thread (sorry), but if the NotifyMgr is giving you trouble because of
> lack-of-stack space (what sort of trouble were you having, precisely?) then its
> probably because it DOES (attempt) to do something about this. In some places
> PalmOS takes a bit of a lazy attitude towards stack space issues, and it causes
> trouble now and again.
My apologies. I was just going on the knowledge that I could gather from the PalmOS
3.0 source. When do you think we could obtain
the 3.3 or 3.5 source? :-)
> But the NotifyMgr is at least a bit better about it...
> Before a notification handler is called (either a callback function or PilotMain
> via SysAppLaunch) NotifyMgr makes sure there are at least 256 bytes of stack
> available. Or at least, thats the theory, and the API test guys said that it
> was working. One of the possible problems here is that I have no idea how much
> stack space is used by SysAppLaunch (if you're not using callback procedures for
> notification), and this comes out of the 256 bytes that are reserved for your
> handler. Also, if your handler calls OS routines that use a lot of stack space,
> then maybe 256 bytes isn't enough.
This was the info. I was originally seeking. Thanks.
> > Well, allocating your own stack would explain a lot. If the stack pointer is
> in
> > this seperate block, then it's outside the range returned by SysStackInfo.
>
> This is a really good point (thanks, Keith!!).
> The code in PrvCheckStackSpace() looks at the range returned by SysStackInfo(),
> and compares it to the current stack pointer. If the SP is within 256 bytes of
> the end, it returns sysNotifyErrNoStackSpace. If the SP has overflowed the end
> of the stack, then you get a fatal error. So, when you allocate your own stack,
> it will either be before or after the "official" stack chunk, and either way its
> outside of the 'official' stack range. One way, it will look as if you've got
> LOTS of stack space left (when you might not, really), and the other way it will
> look as if you've _really_ overflowed your stack (hence you get the fatal error
> when maybe you shouldn't). So, you're either bypassing the NotifyMgr's error
> checking, or you are rendering it useless ('cause it won't broadcast anything).
>
> Does this clear things up a bit?
Things were already cleared up. :-)
My subsequent post stated that I wasn't restoring the app info block correctly. I now
do and I posted the code for others to see.
My app. just broke the 1 million gremlin mark under 3.5 so I'm pretty happy re. stack
issues now.
For the record, my recommendation is that ALL notifications should be sent with a
separate stack from the UI app stack. This stack
could be a once-off allocation of memory and a quick change of A7 and appinfo. This
way, all notification handlers know what free
stack space they're dealing with ALL of the time. The way it is now has been very
problematic for me in the past.
Kind regards,
Christopher
--
Christopher Hunt
Class Action Pty. Ltd.
Complete time zone management for the Palm(tm) connected organizer.
Check out http://www.classactionpl.com/
--
For information on using the Palm Developer Forums, or to unsubscribe, please see
http://www.palm.com/devzone/mailinglists.html
