+haskell-cafe, oops
On Thu, Apr 5, 2012 at 11:04 AM, Gregory Collins g...@gregorycollins.netwrote:
On Wed, Apr 4, 2012 at 10:09 PM, tsuraan tsur...@gmail.com wrote:
It's hard to rule Snap timeouts out; try building snap-core with the
-fdebug flag and running your app with DEBUG=1, you'll
On Thu, Apr 5, 2012 at 12:05 PM, Gregory Collins
g...@gregorycollins.net wrote:
+haskell-cafe, oops
On Thu, Apr 5, 2012 at 11:04 AM, Gregory Collins g...@gregorycollins.net
wrote:
On Wed, Apr 4, 2012 at 10:09 PM, tsuraan tsur...@gmail.com wrote:
It's hard to rule Snap timeouts out; try
I think I might know what your problem is. You're accepting file uploads
using handleMultipart, yes? Snap kills uploads that are going too slow,
otherwise you would be vulnerable to slowloris
(http://ha.ckers.org/slowloris/) DoS attacks. What's probably happening here
is that you're doing
I think I might know what your problem is. You're accepting file uploads
using handleMultipart, yes? Snap kills uploads that are going too slow,
otherwise you would be vulnerable to slowloris
(http://ha.ckers.org/slowloris/) DoS attacks. What's probably happening here
is that you're doing
On Wed, Apr 4, 2012 at 6:37 AM, tsuraan tsur...@gmail.com wrote:
What sorts of things can cause a thread to get an asynchronous thread
killed exception? I've been seeing rare, inexplicable thread
killed messages in my Snap handlers for a long time, but they aren't
from Snap's timeout code.
On Wed, Apr 4, 2012 at 6:37 AM, tsuraan tsur...@gmail.com wrote:
What sorts of things can cause a thread to get an asynchronous thread
killed exception? I've been seeing rare, inexplicable thread
killed messages in my Snap handlers for a long time, but they aren't
from Snap's timeout code.
That's probably not where the threadKill is being sent *from*, it's where
your thread received it.
Yeah, it's definitely where my thread received it. It's just sort of
crazy, because when I get a ThreadKilled, it's almost always in
Tiger.update. My handler does much slower things, such as
This is a long shot, but it's easy to test - turn off GHC's RTS timer,
+RTS -V0 -RTS. That removes a source of SIGALRM interrupts.
Awesome, I'll give that a try. It's worth a shot, anyhow :)
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
This is a long shot, but it's easy to test - turn off GHC's RTS timer,
+RTS -V0 -RTS. That removes a source of SIGALRM interrupts.
I was really hoping this one would reveal something interesting, but
it seems to have no effect. Thanks for the hint though.
It's hard to rule Snap timeouts out; try building snap-core with the
-fdebug flag and running your app with DEBUG=1, you'll get a spew of
debugging output from Snap on stderr.
Heh, that was quite a spew. I normally get the exceptions tens of MB
into files that are hundreds of MB, and I
My Snap handlers communicate with various resource pools, often
through MVars. Is it possible that MVar deadlock would be causing the
runtime system to kill off a contending thread, giving it a
ThreadKilled exception? It looks like ghc does do deadlock detection,
but I can't find any docs on how
Whenever I've deadlocked, it terminated the program with thread
blocked indefinitely in an MVar operation.
On Wed, Apr 4, 2012 at 5:59 PM, tsuraan tsur...@gmail.com wrote:
My Snap handlers communicate with various resource pools, often
through MVars. Is it possible that MVar deadlock would be
Whenever I've deadlocked, it terminated the program with thread
blocked indefinitely in an MVar operation.
Well, I guess that's probably not what I'm seeing. I'm currently
trying to simplify the heck out of the code that near where the thread
killed exceptions are emanating; maybe once that's
What sorts of things can cause a thread to get an asynchronous thread
killed exception? I've been seeing rare, inexplicable thread
killed messages in my Snap handlers for a long time, but they aren't
from Snap's timeout code. I recently upgraded to ghc 7.4.1, and that
caused the kills to happen
14 matches
Mail list logo
