Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Dancer is not compatible with Corona #929
How to reproduce: https://gist.github.com/berekuk/5657189
Result I observed from this gist: thread1 prints "bar…bar…bar…" until I run the thread2 in another console, and then thread1 starts printing "foo…foo…", while thread2 prints "bar…bar…bar…"
PS: It's reproducible both with Dancer and Dancer2.
Okay, that is funky...
I'll have to look at it a mite closer. But as far as I know, Dancer
But yeah, real intriguing. Thanks for the report!
Equivalent code using Web::Simple under Corona does the right thing. Kelp seems to fail worse though.
and the other command (bar):
Notice how it seems to have re-used the request() (and the params()) object
@yanick, it's not really that surprising. Coro threads share everything by default, and Dancer APIs are not object-oriented, and so don't have any means to track the right context when you enter two routes at the same time.
The only solution I can see is to track multiple Dancer::SharedData instances in a hashref, identified by Coro's thread_id.
I don't see how that's possible. I looked into Dancer2 code, and it looks like request is stored in
How do you suggest
added a commit
Jul 21, 2013
I'd prefer more strong wording, I think. More like "Don't even think about using Corona or any other AnyEvent-based server". In all caps, MST-style.
"Can cause" implies that there's a chance it'll be ok. So someone can decide that their app is safe, because they checked it in the browser and it looked like it's working. But it really, really won't. This issue will come up months later in production, and it will be hard to reproduce. In the worst case, users will get the personal data from other users, something they were never meant to see (so this can turn into a big security issue).
Maybe Dancer should just detect AnyEvent presence and die with fatal error.
The way I understand it, it will be okay as long as the application itself doesn't use any AnyEvent
sent on the way, short email!
This is wrong. Dancer 2 creates one context object per request.
So Dancer 2 should behave nicely here and was designed exactly to fix that.
I suggest doing the same tests with a dancer 2 app.
You are describing here the major difference between 1 and 2.
Anything related to D1 globals issues should point to D2.
This is the case here.