Re: [webkit-dev] WTF StackBounds not compatible with Windows fiber threads custom fiber or thread stack size

2011-08-30 Thread Darin Adler
Seems more like a Windows question rather than a WebKit question. Can you get 
the stack size for a Windows thread or not?

On platforms where we don’t know how to get the stack size we just have a fixed 
guess in StackBounds.cpp.

-- Darin

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev


Re: [webkit-dev] WTF StackBounds not compatible with Windows fiber threads custom fiber or thread stack size

2011-08-30 Thread Gavin Barraclough
I had a partially working solution to this using the deallocation stack member 
of the Win32 Thread Information Block, see 
https://bugs.webkit.org/show_bug.cgi?id=26276  
http://en.wikipedia.org/wiki/Win32_Thread_Information_Block – but I didn't 
manage to get this working consistently.  Perhaps a Windows expert may be able 
to build on this.

Bug #26276 would be a great place to be having this discussion, so that 
anything useful is recorded.

cheers,
G.


On Aug 29, 2011, at 9:08 PM, Jacques Quidu wrote:

 Hello,
 
 WTF current implementation of StackBounds is not quite compatible with 
 Windows fiber threads and/or custom stack sizes:
 we have successfully implemented support for Windows fiber threads in 
 StackBounds  fixed some 64 issues but we are still stuck on how to determine 
 thread or fiber allocated stack size...
 
 From the fiber or thread context, i can only get the stack base  stack 
 current pointer but not the allocated stack size: any idea on how to get it 
 assuming that i cannot get stack size from the executable stack size because 
 our main app might use cooperative fiber threads with variable stack size, 
 along with preemptive threads created from WebKit ?
 
 For now the only workaround i think about is to pass the fiber stack size as 
 fiber data while creating the fiber in our main app  get it in StackBounds 
 with GetFiberData() using a custom define to filter with our app impl: but it 
 means adding code specific to our app in JavacriptCore/WTF which i would like 
 to avoid if it is possible.
 
 Kind regards, 
 
 Jacques Quidu
 Graphics Software Engineer
 E-Mail: jqu...@hotmail.fr
 
 ___
 webkit-dev mailing list
 webkit-dev@lists.webkit.org
 http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev


Re: [webkit-dev] lots of red in the tree.

2011-08-30 Thread David Levin
On Tue, Aug 30, 2011 at 10:55 AM, Jarred Nicholls jar...@sencha.com wrote:

 On Tue, Aug 30, 2011 at 1:52 PM, David Levin le...@chromium.org wrote:

 It means that I'm much more likely to cause regressions because I miss new
 test failures caused by my changes among the 12 to 62 failures
 already occurring on the OS X bots.1


 Yeah it was wigging me out this morning.



 I think there are a few solutions to the current situation:

 1. Live with it. All of the red and green reminds us of the festive winter
 holidays.


 presents!


 Downside: More regressions get in as nobody notices them much even if
 they try to be careful.
 Upside: Requires no more extra work, so it is quick to do!

 2. Get folks working on every red test.


 Was thinkin' about diving head first into this.


 Downside: May not be able to get folks to drop what they are doing and
 work on them.
 Upside: More stable code, easier to work with, etc.

 3. Add them to skipped and file bugs.


 Good first step.  Some of the tests are flaky though - I'll get different
 results on subsequent runs.


I'm ok with letting flaky ones run for now as they are re-run by the harness
and won't hide new failures. I would like to take care of those that are
always failing.

I'm in favor of this one -- Adding them to skipped and filing bugs.

dave





 Downside: Not having the tree red may lower the urgency and having
 them in skipped list may mean that folks just ignore them.
 Upside: We'll catch regressions more quickly and perhaps stop the
 current decent which it seems like we've been proceeding on.

 4. Your idea!

 What do other folks think?

 Dave

 ___
 webkit-dev mailing list
 webkit-dev@lists.webkit.org
 http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev




 --
 

 *Sencha*
 Jarred Nicholls, Senior Software Architect
 @jarrednicholls
 http://twitter.com/jarrednicholls


___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev