Re: [Mono-dev] TCP Async

2012-07-06 Thread Yuriy Solodkyy
Hi Rodrigo,

please find a small sample app at https://github.com/ysw/mono-socket-problem

This app can start in either server or client mode.  These modes only
differ in whether it listens for connections on multiple ports or
connects to server on multiple ports. Upon connecting to or accepting
connection it immediately sends some data, and then sends next chunk
of data in response to any data received from the other side.  There
are some random delays in code and we limit outgoing traffic on each
connection not to be significantly higher than inbound.

There is also a separate thread which regularly checks status of every
connection and report any connections that are awaiting a callback,
but their status obtained with socket.poll is already READY.  (A
several seconds delay is still allowed).

See also the README file.


Also, it seems that constantly changing men/max threads in ThreadPool
increases probability of the problem. See code.
Please let me know if this sample app works for you.

Hope it helps


Thank you,
Yuriy


We've been aware of such issues, could you file a bug and attach a test
case with it please?

This would really really help us fix it.

On Wed, Jun 27, 2012 at 4:08 AM, Greg Young  wrote:

> We are experiencing an issue with async behaviours in sockets (with
> SendAsync/callback not Begin/End).
>
> Our visible issue is that when in a send loop we will fail on our
> heartbeats. After debugging and counting calls into/out of
> SendAsync/callback we see that we are inside of a call to SendAsync
> (eg: it never returns, in our case for 10 seconds before we declare
> the socket dead). We can duplicate this fairly regularly on
> mac/bsd/linux though its nonconsistent (sometimes it may happen
> repeatedly other times it works fine). The code does not have such
> issues on MS CLR. We are also running on loopback so its unlikely that
> an underlying network problem is causing the hang up. The code itself
> is fairly straight forward (not that different than the MS example of
> the API except that its fully async (separate send/receive loops while
> the example is request/response))
>
> I am pulling sources now to build latest but does anyone happen to
> know of known issues with this sort of thing?
>
> Cheers,
>
> Greg
>
> --
> Le doute n'est pas une condition agréable, mais la certitude est absurde.
> ___
> Mono-devel-list mailing list
> Mono-devel-list at lists.ximian.com
> http://lists.ximian.com/mailman/listinfo/mono-devel-list
>

-- 
Yuriy Solodkyy
(y.solod...@gmail.com)
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list


Re: [Mono-dev] AOT and generics

2012-07-06 Thread Virgile Bello
Thanks for the confirmation, that's what I could guess as well (one shared
code for every ref instance).
However, in that case, I can't think of any way this code can run because
for every ref type in A, the method B::Test>() will need to be
generated (X being a struct -- it's just like "bringing" a non-shareable
struct type into the shared generic instance). Basically, if the class is
requested with T, if it has any method call depending on T, they should be
generated. It seems to actually be done if B::Test is called but not
B::Test>. There might be some other related cases as well (when
bringing a struct into a generic type). That's why I was suggesting sharing
might be problematic in this case, I will take a look at the code to have a
better idea of it.

Also, I will double check my setup, but it pretty seems standard (other AOT
stuff works fine, experimenting under linux x64).
Anyway, I will fill a bug to not pollute the mailing list too much.

Virgile

On Fri, Jul 6, 2012 at 11:39 PM, Rodrigo Kumpera  wrote:

> The FullAOT compiler handles generics by compiling a single shared
> instance for all ref-only type arguments.
> so List shares code with List but List gets its own
> version. This is the default behavior.
>
> If this is not the case, then you have something broken in your setup.
>
>
> On Fri, Jul 6, 2012 at 11:24 AM, Virgile Bello wrote:
>
>> It would be for platforms supporting only AOT.
>> Of course we would license Mono. We already had a quick discussion about
>> licensing maybe a year ago (it's still R&D/proof of concept for now, and it
>> was only Windows until now so we just delayed actual deal until necessary),
>> but thanks for pointing out, maybe now is a good time to start the
>> discussion again with Xamarin, I will send an email right away.
>>
>>
>> On Fri, Jul 6, 2012 at 10:31 PM, Rodrigo Kumpera wrote:
>>
>>> You need to correctly drive the FullAOT compiler.
>>> Why do you want to use FullAOT anyway?
>>> Do you plan to run it on a target that disables JIT?
>>> Do you hold a license that allows you to do so? Mono is LGPL and FullAOT
>>> doesn't work with it.
>>>
>>> On Fri, Jul 6, 2012 at 9:29 AM, Virgile Bello 
>>> wrote:
>>>
 During full AOT, It seems that if generics is a ref type, AOT is
 skipped (which makes sense because most of the time it is not necessary,
 one codegen for any ref type is usually enough).
 However, if the class internally uses a struct based on the generic
 types, it will fail at runtime.
 Here is a simple example showcasing the issue:

 public class B
 {
 public void Test()
 {
 System.Console.WriteLine(typeof(T));
 }
 }

 public class A
 {
 public void Test()
 {
 new B().Test>();
 }
 }


 class P
 {
 static void Main(string[] args)
 {
 new A().Test();
 new A().Test();
 }
 }

 If I run this program with full aot, it will fail.
 new A will work (AOT forced because value type)
 However, new A will generate a JIT exception (because even
 though string is a ref type, A should be AOT for this specific type because
 KeyValuePair inside A needs to be JITed.)

 But maybe I misunderstood the problem (or it is just a specific bug),
 because this other case actually work (I was expecting it to have the same
 issue):

 public class B
 {
 public void Test()
 {

 System.Console.WriteLine(typeof(System.Collections.Generic.KeyValuePair>>> T>));
 }
 }

 public class A
 {
 public void Test()
 {
 new B().Test();
 }
 }


 class P
 {
 static void Main(string[] args)
 {
 new A().Test();
 new A().Test();
 }
 }

 Just wanted to check if I understood the issue right and if there would
 be nothing preventing from fixing it?
 I wouldn't mind taking a look at the sources by myself if necessary.

 Virgile


 ___
 Mono-devel-list mailing list
 Mono-devel-list@lists.ximian.com
 http://lists.ximian.com/mailman/listinfo/mono-devel-list


>>>
>>
>
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list


Re: [Mono-dev] AOT and generics

2012-07-06 Thread Rodrigo Kumpera
The FullAOT compiler handles generics by compiling a single shared instance
for all ref-only type arguments.
so List shares code with List but List gets its own
version. This is the default behavior.

If this is not the case, then you have something broken in your setup.


On Fri, Jul 6, 2012 at 11:24 AM, Virgile Bello wrote:

> It would be for platforms supporting only AOT.
> Of course we would license Mono. We already had a quick discussion about
> licensing maybe a year ago (it's still R&D/proof of concept for now, and it
> was only Windows until now so we just delayed actual deal until necessary),
> but thanks for pointing out, maybe now is a good time to start the
> discussion again with Xamarin, I will send an email right away.
>
>
> On Fri, Jul 6, 2012 at 10:31 PM, Rodrigo Kumpera wrote:
>
>> You need to correctly drive the FullAOT compiler.
>> Why do you want to use FullAOT anyway?
>> Do you plan to run it on a target that disables JIT?
>> Do you hold a license that allows you to do so? Mono is LGPL and FullAOT
>> doesn't work with it.
>>
>> On Fri, Jul 6, 2012 at 9:29 AM, Virgile Bello wrote:
>>
>>> During full AOT, It seems that if generics is a ref type, AOT is skipped
>>> (which makes sense because most of the time it is not necessary, one
>>> codegen for any ref type is usually enough).
>>> However, if the class internally uses a struct based on the generic
>>> types, it will fail at runtime.
>>> Here is a simple example showcasing the issue:
>>>
>>> public class B
>>> {
>>> public void Test()
>>> {
>>> System.Console.WriteLine(typeof(T));
>>> }
>>> }
>>>
>>> public class A
>>> {
>>> public void Test()
>>> {
>>> new B().Test>();
>>> }
>>> }
>>>
>>>
>>> class P
>>> {
>>> static void Main(string[] args)
>>> {
>>> new A().Test();
>>> new A().Test();
>>> }
>>> }
>>>
>>> If I run this program with full aot, it will fail.
>>> new A will work (AOT forced because value type)
>>> However, new A will generate a JIT exception (because even
>>> though string is a ref type, A should be AOT for this specific type because
>>> KeyValuePair inside A needs to be JITed.)
>>>
>>> But maybe I misunderstood the problem (or it is just a specific bug),
>>> because this other case actually work (I was expecting it to have the same
>>> issue):
>>>
>>> public class B
>>> {
>>> public void Test()
>>> {
>>>
>>> System.Console.WriteLine(typeof(System.Collections.Generic.KeyValuePair>> T>));
>>> }
>>> }
>>>
>>> public class A
>>> {
>>> public void Test()
>>> {
>>> new B().Test();
>>> }
>>> }
>>>
>>>
>>> class P
>>> {
>>> static void Main(string[] args)
>>> {
>>> new A().Test();
>>> new A().Test();
>>> }
>>> }
>>>
>>> Just wanted to check if I understood the issue right and if there would
>>> be nothing preventing from fixing it?
>>> I wouldn't mind taking a look at the sources by myself if necessary.
>>>
>>> Virgile
>>>
>>>
>>> ___
>>> Mono-devel-list mailing list
>>> Mono-devel-list@lists.ximian.com
>>> http://lists.ximian.com/mailman/listinfo/mono-devel-list
>>>
>>>
>>
>
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list


Re: [Mono-dev] AOT and generics

2012-07-06 Thread Virgile Bello
It would be for platforms supporting only AOT.
Of course we would license Mono. We already had a quick discussion about
licensing maybe a year ago (it's still R&D/proof of concept for now, and it
was only Windows until now so we just delayed actual deal until necessary),
but thanks for pointing out, maybe now is a good time to start the
discussion again with Xamarin, I will send an email right away.

On Fri, Jul 6, 2012 at 10:31 PM, Rodrigo Kumpera  wrote:

> You need to correctly drive the FullAOT compiler.
> Why do you want to use FullAOT anyway?
> Do you plan to run it on a target that disables JIT?
> Do you hold a license that allows you to do so? Mono is LGPL and FullAOT
> doesn't work with it.
>
> On Fri, Jul 6, 2012 at 9:29 AM, Virgile Bello wrote:
>
>> During full AOT, It seems that if generics is a ref type, AOT is skipped
>> (which makes sense because most of the time it is not necessary, one
>> codegen for any ref type is usually enough).
>> However, if the class internally uses a struct based on the generic
>> types, it will fail at runtime.
>> Here is a simple example showcasing the issue:
>>
>> public class B
>> {
>> public void Test()
>> {
>> System.Console.WriteLine(typeof(T));
>> }
>> }
>>
>> public class A
>> {
>> public void Test()
>> {
>> new B().Test>();
>> }
>> }
>>
>>
>> class P
>> {
>> static void Main(string[] args)
>> {
>> new A().Test();
>> new A().Test();
>> }
>> }
>>
>> If I run this program with full aot, it will fail.
>> new A will work (AOT forced because value type)
>> However, new A will generate a JIT exception (because even though
>> string is a ref type, A should be AOT for this specific type because
>> KeyValuePair inside A needs to be JITed.)
>>
>> But maybe I misunderstood the problem (or it is just a specific bug),
>> because this other case actually work (I was expecting it to have the same
>> issue):
>>
>> public class B
>> {
>> public void Test()
>> {
>>
>> System.Console.WriteLine(typeof(System.Collections.Generic.KeyValuePair> T>));
>> }
>> }
>>
>> public class A
>> {
>> public void Test()
>> {
>> new B().Test();
>> }
>> }
>>
>>
>> class P
>> {
>> static void Main(string[] args)
>> {
>> new A().Test();
>> new A().Test();
>> }
>> }
>>
>> Just wanted to check if I understood the issue right and if there would
>> be nothing preventing from fixing it?
>> I wouldn't mind taking a look at the sources by myself if necessary.
>>
>> Virgile
>>
>>
>> ___
>> Mono-devel-list mailing list
>> Mono-devel-list@lists.ximian.com
>> http://lists.ximian.com/mailman/listinfo/mono-devel-list
>>
>>
>
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list


Re: [Mono-dev] AOT and generics

2012-07-06 Thread Rodrigo Kumpera
You need to correctly drive the FullAOT compiler.
Why do you want to use FullAOT anyway?
Do you plan to run it on a target that disables JIT?
Do you hold a license that allows you to do so? Mono is LGPL and FullAOT
doesn't work with it.

On Fri, Jul 6, 2012 at 9:29 AM, Virgile Bello wrote:

> During full AOT, It seems that if generics is a ref type, AOT is skipped
> (which makes sense because most of the time it is not necessary, one
> codegen for any ref type is usually enough).
> However, if the class internally uses a struct based on the generic types,
> it will fail at runtime.
> Here is a simple example showcasing the issue:
>
> public class B
> {
> public void Test()
> {
> System.Console.WriteLine(typeof(T));
> }
> }
>
> public class A
> {
> public void Test()
> {
> new B().Test>();
> }
> }
>
>
> class P
> {
> static void Main(string[] args)
> {
> new A().Test();
> new A().Test();
> }
> }
>
> If I run this program with full aot, it will fail.
> new A will work (AOT forced because value type)
> However, new A will generate a JIT exception (because even though
> string is a ref type, A should be AOT for this specific type because
> KeyValuePair inside A needs to be JITed.)
>
> But maybe I misunderstood the problem (or it is just a specific bug),
> because this other case actually work (I was expecting it to have the same
> issue):
>
> public class B
> {
> public void Test()
> {
>
> System.Console.WriteLine(typeof(System.Collections.Generic.KeyValuePair T>));
> }
> }
>
> public class A
> {
> public void Test()
> {
> new B().Test();
> }
> }
>
>
> class P
> {
> static void Main(string[] args)
> {
> new A().Test();
> new A().Test();
> }
> }
>
> Just wanted to check if I understood the issue right and if there would be
> nothing preventing from fixing it?
> I wouldn't mind taking a look at the sources by myself if necessary.
>
> Virgile
>
>
> ___
> Mono-devel-list mailing list
> Mono-devel-list@lists.ximian.com
> http://lists.ximian.com/mailman/listinfo/mono-devel-list
>
>
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list


Re: [Mono-dev] AOT and generics

2012-07-06 Thread Rob Wilkens
I'm not an expert, but i would file a bug report in addition to this
e-mail, if you haven't already - i think things are less likely to be
forgotten in the bug database.

http://mono-project.com/Bugs (and click the green + next to the
appropriate category)

-Rob

On 07/06/2012 08:29 AM, Virgile Bello wrote:
> During full AOT, It seems that if generics is a ref type, AOT is
> skipped (which makes sense because most of the time it is not
> necessary, one codegen for any ref type is usually enough).
> However, if the class internally uses a struct based on the generic
> types, it will fail at runtime.
> Here is a simple example showcasing the issue:
>
> public class B
> {
> public void Test()
> {
> System.Console.WriteLine(typeof(T));
> }
> }
>
> public class A
> {
> public void Test()
> {
> new B().Test>();
> }
> }
>
>
> class P
> {
> static void Main(string[] args)
> {
> new A().Test();
> new A().Test();
> }
> }
>
> If I run this program with full aot, it will fail.
> new A will work (AOT forced because value type)
> However, new A will generate a JIT exception (because even
> though string is a ref type, A should be AOT for this specific type
> because KeyValuePair inside A needs to be JITed.)
>
> But maybe I misunderstood the problem (or it is just a specific bug),
> because this other case actually work (I was expecting it to have the
> same issue):
>
> public class B
> {
> public void Test()
> {
>
> System.Console.WriteLine(typeof(System.Collections.Generic.KeyValuePair T>));
> }
> }
>
> public class A
> {
> public void Test()
> {
> new B().Test();
> }
> }
>
>
> class P
> {
> static void Main(string[] args)
> {
> new A().Test();
> new A().Test();
> }
> }
>
> Just wanted to check if I understood the issue right and if there
> would be nothing preventing from fixing it?
> I wouldn't mind taking a look at the sources by myself if necessary.
>
> Virgile
>
>
>
> ___
> Mono-devel-list mailing list
> Mono-devel-list@lists.ximian.com
> http://lists.ximian.com/mailman/listinfo/mono-devel-list


___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list


[Mono-dev] AOT and generics

2012-07-06 Thread Virgile Bello
During full AOT, It seems that if generics is a ref type, AOT is skipped
(which makes sense because most of the time it is not necessary, one
codegen for any ref type is usually enough).
However, if the class internally uses a struct based on the generic types,
it will fail at runtime.
Here is a simple example showcasing the issue:

public class B
{
public void Test()
{
System.Console.WriteLine(typeof(T));
}
}

public class A
{
public void Test()
{
new B().Test>();
}
}


class P
{
static void Main(string[] args)
{
new A().Test();
new A().Test();
}
}

If I run this program with full aot, it will fail.
new A will work (AOT forced because value type)
However, new A will generate a JIT exception (because even though
string is a ref type, A should be AOT for this specific type because
KeyValuePair inside A needs to be JITed.)

But maybe I misunderstood the problem (or it is just a specific bug),
because this other case actually work (I was expecting it to have the same
issue):

public class B
{
public void Test()
{

System.Console.WriteLine(typeof(System.Collections.Generic.KeyValuePair));
}
}

public class A
{
public void Test()
{
new B().Test();
}
}


class P
{
static void Main(string[] args)
{
new A().Test();
new A().Test();
}
}

Just wanted to check if I understood the issue right and if there would be
nothing preventing from fixing it?
I wouldn't mind taking a look at the sources by myself if necessary.

Virgile
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list