future hangs

[turicum]

Hi everybody!

This simple application hangs at "println(s())". Apparently, the mistake is so simple that I cannot find it... what am I doing wrong? Defining getData and printing s() in the interactive scala shell works just fine. Thanks!

object Test extends Application {

    val s = future(getData("AAPL\n"))
    val t = getData("INTC\n")
    println(t) // that's fine
    println(s()) // hangs here
                                                                                             
    def getData(query: String): String = {
         query
     }
}

[Mark Harrah]

Don't use Application.  Just use a normal main method.  See
http://scala-blogs.org/2008/07/application-trait-considered-harmful.html

-Mark

On Tuesday 07 July 2009, turicum wrote:

> object Test extends Application {
>
>     val s = future(getData("AAPL\n"))
>     val t = getData("INTC\n")
>     println(t) // that's fine
>     println(s()) // hangs here
>                                                                            
>                   def getData(query: String): String = {
>          query
>      }
> }

[turicum]

it works! thanks!
Alessandro

Mark Harrah wrote:

Don't use Application.  Just use a normal main method.  See
http://scala-blogs.org/2008/07/application-trait-considered-harmful.html

-Mark

On Tuesday 07 July 2009, turicum wrote:
> object Test extends Application {
>
>     val s = future(getData("AAPL\n"))
>     val t = getData("INTC\n")
>     println(t) // that's fine
>     println(s()) // hangs here
>                                                                            
>                   def getData(query: String): String = {
>          query
>      }
> }

[Marcus Downing]

Can somebody explain why that makes it work? What about the Application class would break a future? Or what else is going on?


it works! thanks!
Alessandro

Mark Harrah wrote:

Don't use Application.  Just use a normal main method.  See
http://scala-blogs.org/2008/07/application-trait-considered-harmful.html

-Mark

On Tuesday 07 July 2009, turicum wrote:
> object Test extends Application {
>
>     val s = future(getData("AAPL\n"))
>     val t = getData("INTC\n")
>     println(t) // that's fine
>     println(s()) // hangs here
>                                                                            
>                   def getData(query: String): String = {
>          query
>      }
> }

[Arthur Peters]

If you look at the bottom of the blog post
(http://scala-blogs.org/2008/07/application-trait-considered-harmful.html)
you will see:

First, concurrency is broken. The JVM does not allow other threads to
access a class during initialization. You can easily get yourself into
deadlock by writing concurrent code in classes that use Application.
(See Ticket #746)

The basic idea is that threads are not allowed to run concurrently
with the initializer. So the thread that sets the future never runs.

-Arthur



On Tue, Jul 7, 2009 at 9:29 PM, Marcus Downing<marcus@...> wrote:

>
> Can somebody explain why that makes it work? What about the Application class
> would break a future? Or what else is going on?
>
>
> turicum wrote:
>>
>> it works! thanks!
>> Alessandro
>>
>>
>> Mark Harrah wrote:
>>>
>>> Don't use Application.  Just use a normal main method.  See
>>> http://scala-blogs.org/2008/07/application-trait-considered-harmful.html
>>>
>>> -Mark
>>>
>>> On Tuesday 07 July 2009, turicum wrote:
>>>> object Test extends Application {
>>>>
>>>>     val s = future(getData("AAPL\n"))
>>>>     val t = getData("INTC\n")
>>>>     println(t) // that's fine
>>>>     println(s()) // hangs here
>>>>
>>>>
>>>>                   def getData(query: String): String = {
>>>>          query
>>>>      }
>>>> }
>>>
>>>
>>>
>>>
>>
>>
>
> --
> View this message in context: http://www.nabble.com/future-hangs-tp24383831p24383979.html
> Sent from the Scala - User mailing list archive at Nabble.com.
>
>

[Marcus Downing]

I see, thanks. That's quite a gremlin.

Arthur Peters wrote:

If you look at the bottom of the blog post
(http://scala-blogs.org/2008/07/application-trait-considered-harmful.html)
you will see:

First, concurrency is broken. The JVM does not allow other threads to
access a class during initialization. You can easily get yourself into
deadlock by writing concurrent code in classes that use Application.
(See Ticket #746)

The basic idea is that threads are not allowed to run concurrently
with the initializer. So the thread that sets the future never runs.

-Arthur



On Tue, Jul 7, 2009 at 9:29 PM, Marcus Downing<[e-mail]> wrote:
>
> Can somebody explain why that makes it work? What about the Application class
> would break a future? Or what else is going on?
>
>
> turicum wrote:
>>
>> it works! thanks!
>> Alessandro
>>
>>
>> Mark Harrah wrote:
>>>
>>> Don't use Application.  Just use a normal main method.  See
>>> http://scala-blogs.org/2008/07/application-trait-considered-harmful.html
>>>
>>> -Mark
>>>
>>> On Tuesday 07 July 2009, turicum wrote:
>>>> object Test extends Application {
>>>>
>>>>     val s = future(getData("AAPL\n"))
>>>>     val t = getData("INTC\n")
>>>>     println(t) // that's fine
>>>>     println(s()) // hangs here
>>>>
>>>>
>>>>                   def getData(query: String): String = {
>>>>          query
>>>>      }
>>>> }
>>>
>>>
>>>
>>>
>>
>>
>
> --
> View this message in context: http://www.nabble.com/future-hangs-tp24383831p24383979.html
> Sent from the Scala - User mailing list archive at Nabble.com.
>
>

[Detering Dirk-2]

Nice subject ...

> This simple application hangs at "println(s())". Apparently,
> the mistake is so simple that I cannot find it... what am I
> doing wrong? Defining getData and printing s() in the
> interactive scala shell works just fine. Thanks!
>
> object Test extends Application {
>
>     val s = future(getData("AAPL\n"))
>     val t = getData("INTC\n")
>     println(t) // that's fine
>     println(s()) // hangs here

Well, the println(s()) will first wait for the result of s,
but -due to the definition of s- that doesn't come now, but
in future.

Due to the functional aspect, this is true for every point in time.

(I would recommend renaming the val s into val godot,
and then putting the println(godot()) into a method called
"mañana"...).


Ðet


PS: No, I'm NOT stressed, Mum!!!!

[Ricky Clarkson]

Yet again, "let's remove Application".

2009/7/8 Detering Dirk <Dirk.Detering@...>:

> Nice subject ...
>
>> This simple application hangs at "println(s())". Apparently,
>> the mistake is so simple that I cannot find it... what am I
>> doing wrong? Defining getData and printing s() in the
>> interactive scala shell works just fine. Thanks!
>>
>> object Test extends Application {
>>
>>     val s = future(getData("AAPL\n"))
>>     val t = getData("INTC\n")
>>     println(t) // that's fine
>>     println(s()) // hangs here
>
> Well, the println(s()) will first wait for the result of s,
> but -due to the definition of s- that doesn't come now, but
> in future.
>
> Due to the functional aspect, this is true for every point in time.
>
> (I would recommend renaming the val s into val godot,
> and then putting the println(godot()) into a method called
> "mañana"...).
>
>
> Ðet
>
>
> PS: No, I'm NOT stressed, Mum!!!!
>

--
Ricky Clarkson
Java Programmer, AD Holdings
[phone]
Skype: ricky_clarkson
Google Talk: ricky.clarkson@...

[Marcus Downing]

Is removing Application sufficient? The idiom that Application embodies is bound to happen again in other people's code. Shouldn't either the creation or accessing of the future throw an exception, if called from within a constructor?

Ricky Clarkson wrote:

Yet again, "let's remove Application".

2009/7/8 Detering Dirk <[e-mail]>:
> Nice subject ...
>
>> This simple application hangs at "println(s())". Apparently,
>> the mistake is so simple that I cannot find it... what am I
>> doing wrong? Defining getData and printing s() in the
>> interactive scala shell works just fine. Thanks!
>>
>> object Test extends Application {
>>
>>     val s = future(getData("AAPL\n"))
>>     val t = getData("INTC\n")
>>     println(t) // that's fine
>>     println(s()) // hangs here
>
> Well, the println(s()) will first wait for the result of s,
> but -due to the definition of s- that doesn't come now, but
> in future.
>
> Due to the functional aspect, this is true for every point in time.
>
> (I would recommend renaming the val s into val godot,
> and then putting the println(godot()) into a method called
> "mañana"...).
>
>
> Ðet
>
>
> PS: No, I'm NOT stressed, Mum!!!!
>



--
Ricky Clarkson
Java Programmer, AD Holdings
[phone]
Skype: ricky_clarkson
Google Talk: [e-mail]

[Dimitris Andreou]

But the problem isn't the constructor, it's the class initialization.

2009/7/8 Marcus Downing <marcus@...>

Is removing Application sufficient? The idiom that Application embodies is
bound to happen again in other people's code. Shouldn't either the creation
or accessing of the future throw an exception, if called from within a
constructor?

Ricky Clarkson wrote:
>
> Yet again, "let's remove Application".
>
> 2009/7/8 Detering Dirk <Dirk.Detering@...>:
>> Nice subject ...
>>
>>> This simple application hangs at "println(s())". Apparently,
>>> the mistake is so simple that I cannot find it... what am I
>>> doing wrong? Defining getData and printing s() in the
>>> interactive scala shell works just fine. Thanks!
>>>
>>> object Test extends Application {
>>>
>>>     val s = future(getData("AAPL\n"))
>>>     val t = getData("INTC\n")
>>>     println(t) // that's fine
>>>     println(s()) // hangs here
>>
>> Well, the println(s()) will first wait for the result of s,
>> but -due to the definition of s- that doesn't come now, but
>> in future.
>>
>> Due to the functional aspect, this is true for every point in time.
>>
>> (I would recommend renaming the val s into val godot,
>> and then putting the println(godot()) into a method called
>> "mañana"...).
>>
>>
>> Ðet
>>
>>
>> PS: No, I'm NOT stressed, Mum!!!!
>>
>
>
>
> --
> Ricky Clarkson
> Java Programmer, AD Holdings
> [phone]
> Skype: ricky_clarkson
> Google Talk: ricky.clarkson@...
>
>

--
View this message in context: http://www.nabble.com/future-hangs-tp24383831p24390827.html

Sent from the Scala - User mailing list archive at Nabble.com.

[Viktor Klang]

Remove Application in 2.8?

On Wed, Jul 8, 2009 at 2:55 PM, Jim Andreou <jim.andreou@...> wrote:

But the problem isn't the constructor, it's the class initialization.

2009/7/8 Marcus Downing <marcus@...>

Is removing Application sufficient? The idiom that Application embodies is
bound to happen again in other people's code. Shouldn't either the creation
or accessing of the future throw an exception, if called from within a
constructor?

Ricky Clarkson wrote:
>
> Yet again, "let's remove Application".
>
> 2009/7/8 Detering Dirk <Dirk.Detering@...>:
>> Nice subject ...
>>
>>> This simple application hangs at "println(s())". Apparently,
>>> the mistake is so simple that I cannot find it... what am I
>>> doing wrong? Defining getData and printing s() in the
>>> interactive scala shell works just fine. Thanks!
>>>
>>> object Test extends Application {
>>>
>>>     val s = future(getData("AAPL\n"))
>>>     val t = getData("INTC\n")
>>>     println(t) // that's fine
>>>     println(s()) // hangs here
>>
>> Well, the println(s()) will first wait for the result of s,
>> but -due to the definition of s- that doesn't come now, but
>> in future.
>>
>> Due to the functional aspect, this is true for every point in time.
>>
>> (I would recommend renaming the val s into val godot,
>> and then putting the println(godot()) into a method called
>> "mañana"...).
>>
>>
>> Ðet
>>
>>
>> PS: No, I'm NOT stressed, Mum!!!!
>>
>
>
>
> --
> Ricky Clarkson
> Java Programmer, AD Holdings
> [phone]
> Skype: ricky_clarkson
> Google Talk: ricky.clarkson@...
>
>

--
View this message in context: http://www.nabble.com/future-hangs-tp24383831p24390827.html

Sent from the Scala - User mailing list archive at Nabble.com.

--
Viktor Klang
Scala Loudmouth

[Josh Suereth]

On Wed, Jul 8, 2009 at 9:03 AM, Viktor Klang <viktor.klang@...> wrote:

Remove Application in 2.8?

+30
 

Although, I'd rather see it replaced by something like David MacIver's "Optional" library: http://github.com/DRMacIver/optional/tree/master

- Josh

[Dimitris Andreou]

+300

- This is blasphemy! This is madness!

- This is Scalta!

2009/7/8 Josh Suereth <joshua.suereth@...>

On Wed, Jul 8, 2009 at 9:03 AM, Viktor Klang <viktor.klang@...> wrote:

Remove Application in 2.8?

+30
 

Although, I'd rather see it replaced by something like David MacIver's "Optional" library: http://github.com/DRMacIver/optional/tree/master

- Josh

[Kevin Wright-4]

Got my vote!
+3000

On Wed, Jul 8, 2009 at 2:12 PM, Jim Andreou <jim.andreou@...> wrote:

+300

- This is blasphemy! This is madness!

- This is Scalta!

2009/7/8 Josh Suereth <joshua.suereth@...>

On Wed, Jul 8, 2009 at 9:03 AM, Viktor Klang <viktor.klang@...> wrote:

Remove Application in 2.8?

+30
 

Although, I'd rather see it replaced by something like David MacIver's "Optional" library: http://github.com/DRMacIver/optional/tree/master

- Josh

[Christos KK Loverdos]

lol

[Incidentally, I have just returned from a trip to Sparta :-) .] 

On Jul 8, 2009, at 4:12 PM, Jim Andreou wrote:

+300

- This is blasphemy! This is madness!

- This is Scalta!

2009/7/8 Josh Suereth <joshua.suereth@...>

On Wed, Jul 8, 2009 at 9:03 AM, Viktor Klang <viktor.klang@...> wrote:

Remove Application in 2.8?

+30
 

Although, I'd rather see it replaced by something like David MacIver's "Optional" library: http://github.com/DRMacIver/optional/tree/master

- Josh

-- 
 __~O
-\ <,       Christos KK Loverdos
(*)/ (*)      http://ckkloverdos.com

[Naftoli Gugenheim]

Is there any way to detect if code is running in a static initialization?

-------------------------------------
Christos KK Loverdos<loverdos@...> wrote:

lol

[Incidentally, I have just returned from a trip to Sparta :-) .]


On Jul 8, 2009, at 4:12 PM, Jim Andreou wrote:

> +300
>
> - This is blasphemy! This is madness!
> - This is Scalta!
>
> 2009/7/8 Josh Suereth <joshua.suereth@...>
>
>
> On Wed, Jul 8, 2009 at 9:03 AM, Viktor Klang  
> <viktor.klang@...> wrote:
> Remove Application in 2.8?
>
> +30
>
> Although, I'd rather see it replaced by something like David  
> MacIver's "Optional" library: http://github.com/DRMacIver/optional/tree/master
>
> - Josh
>

--
  __~O
-\ <,       Christos KK Loverdos
(*)/ (*)      http://ckkloverdos.com

[Dimitris Andreou]

Yeah, but it's ultra ugly. Search for a <clinit> method in the stack trace. Then sue yourself for doing it.

2009/7/8 Naftoli Gugenhem <naftoligug@...>

Is there any way to detect if code is running in a static initialization?

-------------------------------------

Christos KK Loverdos<loverdos@...> wrote:

lol

[Incidentally, I have just returned from a trip to Sparta :-) .]


On Jul 8, 2009, at 4:12 PM, Jim Andreou wrote:

> +300
>
> - This is blasphemy! This is madness!
> - This is Scalta!
>
> 2009/7/8 Josh Suereth <joshua.suereth@...>
>
>
> On Wed, Jul 8, 2009 at 9:03 AM, Viktor Klang
> <viktor.klang@...> wrote:
> Remove Application in 2.8?
>
> +30
>
> Although, I'd rather see it replaced by something like David
> MacIver's "Optional" library: http://github.com/DRMacIver/optional/tree/master
>
> - Josh
>

--
 __~O
-\ <,       Christos KK Loverdos
(*)/ (*)      http://ckkloverdos.com

[Naftoli Gugenheim]

So the safety is not worth the "ugliness" for thread-based utilities such as future to check for it? As someone pointed out, such bugs can come even without Application.
(I'm suggesting the check for the library, not for user code. Also, I suppose someone might be able to put such a check for these methods in an aspect...)
-------------------------------------
Jim Andreou<jim.andreou@...> wrote:

Yeah, but it's ultra ugly. Search for a <clinit> method in the stack trace.
Then sue yourself for doing it.
2009/7/8 Naftoli Gugenhem <naftoligug@...>

> Is there any way to detect if code is running in a static initialization?
>
> -------------------------------------
> Christos KK Loverdos<loverdos@...> wrote:
>
> lol
>
> [Incidentally, I have just returned from a trip to Sparta :-) .]
>
>
> On Jul 8, 2009, at 4:12 PM, Jim Andreou wrote:
>
> > +300
> >
> > - This is blasphemy! This is madness!
> > - This is Scalta!
> >
> > 2009/7/8 Josh Suereth <joshua.suereth@...>
> >
> >
> > On Wed, Jul 8, 2009 at 9:03 AM, Viktor Klang
> > <viktor.klang@...> wrote:
> > Remove Application in 2.8?
> >
> > +30
> >
> > Although, I'd rather see it replaced by something like David
> > MacIver's "Optional" library:
> http://github.com/DRMacIver/optional/tree/master
> >
> > - Josh
> >
>
> --
>  __~O
> -\ <,       Christos KK Loverdos
> (*)/ (*)      http://ckkloverdos.com
>
>
>
>
>
>

[Dimitris Andreou]

That check would (slowly, did I mention?) transform a deadlock to an exception - but both are unrecoverable conditions which require stopping and fixing the code anyway.

 

2009/7/8 Naftoli Gugenhem <naftoligug@...>

So the safety is not worth the "ugliness" for thread-based utilities such as future to check for it? As someone pointed out, such bugs can come even without Application.
(I'm suggesting the check for the library, not for user code. Also, I suppose someone might be able to put such a check for these methods in an aspect...)
-------------------------------------

Jim Andreou<jim.andreou@...> wrote:

Yeah, but it's ultra ugly. Search for a <clinit> method in the stack trace.
Then sue yourself for doing it.
2009/7/8 Naftoli Gugenhem <naftoligug@...>

> Is there any way to detect if code is running in a static initialization?
>
> -------------------------------------
> Christos KK Loverdos<loverdos@...> wrote:
>
> lol
>
> [Incidentally, I have just returned from a trip to Sparta :-) .]
>
>
> On Jul 8, 2009, at 4:12 PM, Jim Andreou wrote:
>
> > +300
> >
> > - This is blasphemy! This is madness!
> > - This is Scalta!
> >
> > 2009/7/8 Josh Suereth <joshua.suereth@...>
> >
> >
> > On Wed, Jul 8, 2009 at 9:03 AM, Viktor Klang
> > <viktor.klang@...> wrote:
> > Remove Application in 2.8?
> >
> > +30
> >
> > Although, I'd rather see it replaced by something like David
> > MacIver's "Optional" library:
> http://github.com/DRMacIver/optional/tree/master
> >
> > - Josh
> >
>
> --
>  __~O
> -\ <,       Christos KK Loverdos
> (*)/ (*)      http://ckkloverdos.com
>
>
>
>
>
>

[Naftoli Gugenheim]

I'm not sure what you mean by unrecoverable. You can catch an exception -- but if you're smart enough to think about catching it you know that you're causing it in the first place. (Although if the exception is caught by an outer code block that's agnostic of your erroneous implementation then you have to some extent recovered.)
In any case, who wouldn't prefer a terminating exception to a hanging deadlock? An exception tells you exactly what went wrong and where it went wrong.
Although if it's slow, like you say, then I agree that it may be too much of a price to pay to save the unwise from mysterious hangs...

-------------------------------------
Jim Andreou<jim.andreou@...> wrote:

That check would (slowly, did I mention?) transform a deadlock to an
exception - but both are unrecoverable conditions which require stopping and
fixing the code anyway.
2009/7/8 Naftoli Gugenhem <naftoligug@...>

> So the safety is not worth the "ugliness" for thread-based utilities such
> as future to check for it? As someone pointed out, such bugs can come even
> without Application.
> (I'm suggesting the check for the library, not for user code. Also, I
> suppose someone might be able to put such a check for these methods in an
> aspect...)
> -------------------------------------
> Jim Andreou<jim.andreou@...> wrote:
>
> Yeah, but it's ultra ugly. Search for a <clinit> method in the stack trace.
> Then sue yourself for doing it.
> 2009/7/8 Naftoli Gugenhem <naftoligug@...>
>
> > Is there any way to detect if code is running in a static initialization?
> >
> > -------------------------------------
> > Christos KK Loverdos<loverdos@...> wrote:
> >
> > lol
> >
> > [Incidentally, I have just returned from a trip to Sparta :-) .]
> >
> >
> > On Jul 8, 2009, at 4:12 PM, Jim Andreou wrote:
> >
> > > +300
> > >
> > > - This is blasphemy! This is madness!
> > > - This is Scalta!
> > >
> > > 2009/7/8 Josh Suereth <joshua.suereth@...>
> > >
> > >
> > > On Wed, Jul 8, 2009 at 9:03 AM, Viktor Klang
> > > <viktor.klang@...> wrote:
> > > Remove Application in 2.8?
> > >
> > > +30
> > >
> > > Although, I'd rather see it replaced by something like David
> > > MacIver's "Optional" library:
> > http://github.com/DRMacIver/optional/tree/master
> > >
> > > - Josh
> > >
> >
> > --
> >  __~O
> > -\ <,       Christos KK Loverdos
> > (*)/ (*)      http://ckkloverdos.com
> >
> >
> >
> >
> >
> >
>