To comment on the following update, log in, then open the issue:
http://www.openoffice.org/issues/show_bug.cgi?id=68890
------- Additional comments from [EMAIL PROTECTED] Mon Oct 23 09:22:22 -0700
2006 -------
> First, could you please comment on Kay's questions (and comments)?
Sure.
> - If I understand correctly, reducing the stack sizes currently only reduces
> the (virtual) address room occupied. As we currently do not seem to have any
> problems with this, why should we reduce it? AFAIK, it basically comes with
> no price and only introduces risks (stackoverflow).
Well - there are of course some kernel resources backing the address space,
how much / significant they are I don't know.
> - Why do you want to provide the stack size in frames? IMHO, specifying
> the size in bytes is mostly accurate and directly mimics
> "pthread_attr_setstacksize". You only can guess an average frame size,
> or, why should the frame size be 128?
It sucks as you say :-) I have no idea, I guess what I wanted to do was have
some multiple of sizeof (void *) to make it common across 64bit platforms - and
128bytes is a guess at an average method stack size. But if you prefer bytes
that's fine by me :-)
> - IMHO, the name "osl_createThreadWithStack" is misleading, as any
> created thread has a stack anyway. Something like
> osl_createThreadWithStacksize" might be more appropriate, so providing
> new functions for every attribute, may be even in different combinations,
> does not scale too good.
Sure - it's unfortunate that the property has to be set at construction tie
(for obvious reasons).
> - You shouldn't need to patch VOS, VOS is outdated, obsolet and should
> be removed.
But rather widely used sadly [ and rather easier to use for this case ]
> particular, any comment on the increased risk of stack overflow?
> Is this increased risk really worth such a cosmetic change?
Well - we have to fight a perception of 'bloat' out there among the teen
hackers, and I think the risk is really rather low. We do this only for the
simple helper threads with well defined tasks & behaviors.
> Second, when we would apply your proposed change, I also feel that
> specifying a stack size in Bytes would be the more "natural" API (i.e.
> more similar to what everyone can read in the pthreads documentation).
Sure, looking at it it sucks :-) there is no need to convince me: mea culpa
- my interest was really just genericising 32/64bit thing I guess.
> Third, when we would apply your proposed change, and taking the
> above mentioned additional risk of thread stack overflows into
> account, I'd propose to use a new default stack size of 1MB for
> 32bit (and 2MB for 64bit) (which happen to be the default sizes
> for Solaris).
Sounds perfect - then we take almost no risk, since we know this works on
Solaris alreary :-)
Do you want me to make up a new patch ?
---------------------------------------------------------------------
Please do not reply to this automatically generated notification from
Issue Tracker. Please log onto the website and enter your comments.
http://qa.openoffice.org/issue_handling/project_issues.html#notification
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
