Dynamic Proxy for Silverlight

[Staxxx]

Hello All,

DISCLAIMER: I'm not very familiar with the Castle project in general. My goal is to get a mocking framework supported under silverlight and the only two open source frameworks I know of (Moq & Rhino...) depend on the dynamic proxy so I figure we start here... 

I've attached a patch that I hope could work, however, below I'll list a few things that still need work in silverlight or in general.

1. Should double/tripple check the logic of the included ThreadSafeDictionary<TKey,TValue>

2. In MethodEmitter.CopyParametersAndReturnTypeFrom() there is a method call not exposed to Silverlight because I don't know how to get at baseMethod.ReturnParameter.GetRequiredCustomModifiers() and  baseMethod.ReturnParameter.GetOptionalCustomModifiers().

3. I left some compiler directive #warning's in the code at places that either need some extra thought or need to be just excluded for silverlight

4. I couldn't figure out (in an afternoon) how to successfully sign an assembly in silverlight (ModuleScope.GetAssemblyName()) there's some thoughts there, but I'm leaving any of the unit tests that depend on that failing currently.

5. There are a number of Tests that relied on SerializableClassTestCase.SerializableInterceptorSelector and I just excluded those from silverlight, didn't dig into what they were testing and if there should be silverlight coverage for their purpose.

6. Also I can't say I know or followed the assembly naming standard correctly or how the AssemblyInfo.cs is created/used...

Please let me know how this patch looks, what needs special attention, or if anyone can help with any of what I listed above.

Thanks,
Jason Jarrett

[hammett]

I reviewed it. Overall it looks fine. The only things that prevents me
from applying are

1 - Extension methods on System.* namespace. As a guideline this is
strongly discouraged.
"Just because you can doesnt mean you should"

2 - The RWLock code from Mono. I'd rather have - like I mentioned
before - our special locker on Castle.Core that use RWLocker (or
preferably RWLSlim) for .net and Monitor for SL.

3 - The new exceptions added. Either we always throw specific
exceptions or generic ones.

I'm willing to apply the patch as soon as we discuss and fix these points.

Thanks for the effort

--
Cheers,
hammett
http://hammett.castleproject.org/

[Staxxx]

Hello,

Thanks for taking a look at the patch so quickly... I have a response for each below.

1 - Extension methods on System.* namespace. As a guideline this is
strongly discouraged.
"Just because you can doesnt mean you should"

Good point, I moved them into Castle.DynamicProxy.SilverlightExtensions and added the needed usings in their respective places in my working set already...

2 - The RWLock code from Mono. I'd rather have - like I mentioned
before - our special locker on Castle.Core that use RWLocker (or
preferably RWLSlim) for .net and Monitor for SL.

I didn't want to push too far down implementing this on my own because of a lack of knowledge of what the RWL was doing/how it's being used and am not all that familiar with Monitors, however this sounds like a good time to learn so I will start to take a look...

3 - The new exceptions added. Either we always throw specific
exceptions or generic ones.

Not sure what you mean by this, the added exceptions are specific exceptions. Or are you referring to in silverlight it might throw "MySpecialException" and in the full framework it would throw "ApplicationException"? If this is your concern that's great, can we replace the ApplicatoinExceptions with MySpecialException? I didn't do that in the full framework version because I didn't know if there was anything out there that depended on those exceptions being thrown...

Thanks again,

Jason

[Staxxx]

Hello,

With the ReaderWriterLock could we use the one that is commented out in the Castle.Core SilverlightExtensions? Are there issues with using that as opposed to something else?

Sorry for my ignorance, I'm a little over my head w/ how to write my own ReaderWriterLock...

Also, I took that same version and all the unit tests pass with it (however I don't know if there any multi-threaded tests there...)

Thoughts?

[hammett]

On Sat, Dec 27, 2008 at 9:03 PM, Staxxx <sta...@gmail.com> wrote:
> Hello,

> With the ReaderWriterLock could we use the one that is commented out in the
> Castle.Core SilverlightExtensions?

Sure, you can use that. Just change its name and namespace.

[Staxxx]

Any followup on #3?

3 - The new exceptions added. Either we always throw specific
exceptions or generic ones.

Not sure what you mean by this, the added exceptions are specific exceptions. Or are you referring to in silverlight it might throw "MySpecialException" and in the full framework it would throw "ApplicationException"? If this is your concern that's great, can we replace the ApplicatoinExceptions with MySpecialException? I didn't do that in the full framework version because I didn't know if there was anything out there that depended on those exceptions being thrown...

On Sat, Dec 27, 2008 at 7:01 PM, Staxxx <sta...@gmail.com> wrote:

[hammett]

I'd say that while AppException is too general, ConstructorNotFound is
too specific. You should try to use ProxyGenerationException, and be
consistent - SL and non-SL should throw the same exceptions.

[Staxxx]

Hello,

Let me know how this patch looks...

FYI: double check the SlimReaderWriterLock as I'm not completely comfortable with that...

Thanks,
Jason

[Krzysztof Koźmic]

Jason,

Take a look at MEF codebase. Last time I checked it had an
implementation of a lock that does just that:
wraps a ReaderWriterLockSlim for non-silverlight apps, and Monitor calls
for Silverlight.
Since its MS-PL I think it's ok to use that code.
Hammett?

Cheers,

Krzysztof

Staxxx pisze:

[Staxxx]

Krzysztof, Thanks for the suggestion... 

I just took a look and it looks like their Silverlight implementation is very similar to what's in my patch...

However if their implementation looks better I'd be happy to try and leverage that???

[hammett]

I'll let you know after reviewing the patch. Thx

2008/12/29 Staxxx <sta...@gmail.com>:

--
Cheers,
hammett
http://hammett.castleproject.org/

[Staxxx]

FYI: I guess I was wrong about silverlight not supporting any serialization. I just learned you can add a reference to System.Xml.Serialization.

Not sure how that compares to what's already in the DP, but if serialization is a must have (in silverlight), that could be a path to explore...

2008/12/29 hammett <ham...@gmail.com>

[hammett]

You shouldnt worry about. I really can't see how serialization of
proxies would make sense in a SL app.

2008/12/29 Staxxx <sta...@gmail.com>:

[hammett]

The SlimReaderWriterLock still wrong. Check MEF's codebase please.

[Staxxx]

Hello,

Here's another revision of the Silverlight patch.

The only thing I mimicked about the MEF version is leveraging the Microsoft System.Threading.ReaderWriterLockSlim under the hood in the full framework version...

The way it's being used in the dynamic proxy required the 'upgrade from reader to writer' scenario. When we call EnterReadLock/ExitReadLock on the full framework it's actually calling EnterUpgradeableReadLock/ExitUpgradeableReadLock so the subsequent EnterWriteLock/ExitWriteLock wouldn't fail with an exception.

If this isn't going to work, would you mind coaching me a little more on what specifically isn't correct? I'd like to attempt to write some unit tests around any scenarios this thing may need to specifically support.

Thanks,

Jason

[hammett]

Yep, looks good now. Thanks

[hammett]

Applied. Thanks

[Staxxx]

Great, Thanks...

[Staxxx]

When do you think we will see the "official" binary of the Silverlight Dynamic Proxy?

On Sat, Jan 3, 2009 at 12:18 PM, hammett <ham...@gmail.com> wrote:

[hammett]

When we get our build files adapted to sl, which I have no idea how to do it..

[Staxxx]

At work, we're just using MSBuild to build the silverlight projects files etc... How do you want them to build?

[Jonathon Rossi]

At work, we're just using MSBuild to build the silverlight projects files etc... How do you want them to build?

 

Just about all of castle is build with csc. We have net-2.0, net-3.5 and mono-1.0 directories in the build output, maybe a silverlight-1.0 directory (if this is actually targeting 1.0). The build scripts would also need to run the unit tests for the Core and DP2. I can't remember how the scripts are written to know how hard it would be to just be able to build Core and DP2 when doing a silverlight build.

Is that what you meant by "how do you want them to build"?

--
Jonathon Rossi

[Staxxx]

Yes, that's a good start... It would be Silverlight 2.0, but I'm not sure how to use csc w/ Silverlight (yet).

Thanks

[Staxxx]

I don't have time to work on this any time soon, but this may be helpful???

http://weblogs.asp.net/mschwarz/archive/2007/06/05/how-to-create-silverlight-applications-with-notepad.aspx

[Yuriy Ostapenko]

Hello all,

Today I updated to the latest Castle trunk.
After that my project gone crazy - seems like some really weird
locking issues all over the place.
Please note I use Windsor all over the place and NHibernate uses it as
well (I use it through AR).
Not sure if this issue only occurs within a web context, but this is
99% sure a fault of this patch.
I tried NHibernate.ByteCode.LingFu and it works way better this way
but threads sometimes still seem to get lost when Windsor proxies are
used.
Then i simply rolled (only) DynamicProxy stuff to rev. 5471 and
everything is ok now.
Has anyone else experienced issues similar to mine and can confirm
this?

Thanks
On Jan 4, 2:52 am, Staxxx <sta...@gmail.com> wrote:
> I don't have time to work on this any time soon, but this may be helpful???http://weblogs.asp.net/mschwarz/archive/2007/06/05/how-to-create-silv...

>
> On Sat, Jan 3, 2009 at 5:21 PM, Staxxx <sta...@gmail.com> wrote:
>
> > Yes, that's a good start... It would be Silverlight 2.0, but I'm not sure
> > how to use csc w/ Silverlight (yet).
>
> > Thanks
>

[hammett]

Please expand on "some really weird locking issues all over the place"

[Yuriy Ostapenko]

Didn't dig too much really, but threads stop executing at different
points that involve proxied calls.
I guess they are getting into some deadlock.
The same method calls can execute 5 times in a row and then get
blocked, next time it's a completely different method call... no
system really,
but probably, since NHibernate uses DynamicProxy more extensively than
I do with Windsor, it happens mostly inside actual queries,
so using LingFu for NHibernate helps making those locks occur way less
often.

If you can point me at what other info might be useful, please do so.

Thanks

[hammett]

Ok, I will re-review the commit and worst case scenario I'll revert it.
Thanks

[hammett]

I've just double checked the changes. The ThreadSafeDictionary looks a
bit suspicious. I've removed it and updated the code that used to use
it to lock the access to the dictionary. Please give it a try again.

[Yuriy Ostapenko]

Sorry for bringing bad news, but the issue still remains in the latest
version :(

I now used JMeter to run queries against one of my controller methods
with several worker threads each running 100 samples.
The method is executing fairly complex NHibernate Criteria API based
query against a product catalog database.
It works fine with both DynamicProxy from rev. 5471 and with LinFu
ByteCode provider.
Using the latest DynamicProxy causes some JMeter worker threads to
hang until Cassini or IIS restart (I tried both),
while other threads can successfully execute all samples up to the
last one.

Thanks

On Jan 7, 6:50 am, hammett <hamm...@gmail.com> wrote:
> I've just double checked the changes. The ThreadSafeDictionary looks a
> bit suspicious. I've removed it and updated the code that used to use
> it to lock the access to the dictionary. Please give it a try again.
>
>
>
> On Tue, Jan 6, 2009 at 4:43 AM, hammett <hamm...@gmail.com> wrote:
> > Ok, I will re-review the commit and worst case scenario I'll revert it.
> > Thanks
>

[Ayende Rahien]

Can you break into cassini when it is hanging and produce the stack traces?

[Yuriy Ostapenko]

All Cassini worker threads end up looking this way:

~22e!clrstack
OS Thread Id: 0x348 (22)
ESP EIP
096fcb54 7c90e4f4 [HelperMethodFrame_1OBJ: 096fcb54]
System.Threading.WaitHandle.WaitOneNative
(Microsoft.Win32.SafeHandles.SafeWaitHandle, UInt32, Boolean, Boolean)
096fcc00 792b687f System.Threading.WaitHandle.WaitOne(Int64, Boolean)
096fcc1c 792b6835 System.Threading.WaitHandle.WaitOne(Int32, Boolean)
096fcc30 6c3544fc System.Threading.ReaderWriterLockSlim.WaitOnEvent
(System.Threading.EventWaitHandle, UInt32 ByRef, Int32)
096fcc68 6c353eaf
System.Threading.ReaderWriterLockSlim.TryEnterUpgradeableReadLock
(Int32)
096fcc84 6c353f48
System.Threading.ReaderWriterLockSlim.EnterUpgradeableReadLock()
096fcc88 042ce104
Castle.Core.Internal.SlimReaderWriterLock.EnterReadLock()
096fcc8c 06977f98
Castle.DynamicProxy.Generators.ClassProxyGenerator.GenerateCode
(System.Type[], Castle.DynamicProxy.ProxyGenerationOptions)
096fce7c 06977f19
Castle.DynamicProxy.DefaultProxyBuilder.CreateClassProxy(System.Type,
System.Type[], Castle.DynamicProxy.ProxyGenerationOptions)
096fce98 06977dab Castle.DynamicProxy.ProxyGenerator.CreateClassProxy
(System.Type, System.Type[],
Castle.DynamicProxy.ProxyGenerationOptions, System.Object[],
Castle.Core.Interceptor.IInterceptor[])
096fcec0 06977d36 Castle.DynamicProxy.ProxyGenerator.CreateClassProxy
(System.Type, System.Type[], Castle.Core.Interceptor.IInterceptor[])
096fcecc 06977a7d NHibernate.ByteCode.Castle.ProxyFactory.GetProxy
(System.Object, NHibernate.Engine.ISessionImplementor)
096fcf1c 0697790b
NHibernate.Tuple.Entity.AbstractEntityTuplizer.CreateProxy
(System.Object, NHibernate.Engine.ISessionImplementor)
096fcf2c 069778d6
NHibernate.Persister.Entity.AbstractEntityPersister.CreateProxy
(System.Object, NHibernate.Engine.ISessionImplementor)
096fcf44 0697698b
NHibernate.Event.Default.DefaultLoadEventListener.CreateProxyIfNecessary
(NHibernate.Event.LoadEvent,
NHibernate.Persister.Entity.IEntityPersister,
NHibernate.Engine.EntityKey, NHibernate.Event.LoadType,
NHibernate.Engine.IPersistenceContext)
096fcf68 06974a89
NHibernate.Event.Default.DefaultLoadEventListener.ProxyOrLoad
(NHibernate.Event.LoadEvent,
NHibernate.Persister.Entity.IEntityPersister,
NHibernate.Engine.EntityKey, NHibernate.Event.LoadType)
096fcf98 0697485b
NHibernate.Event.Default.DefaultLoadEventListener.OnLoad
(NHibernate.Event.LoadEvent, NHibernate.Event.LoadType)
096fcfd4 069746da NHibernate.Impl.SessionImpl.FireLoad
(NHibernate.Event.LoadEvent, NHibernate.Event.LoadType)
096fcfec 06974185 NHibernate.Impl.SessionImpl.InternalLoad
(System.String, System.Object, Boolean, Boolean)
096fd010 0697405b NHibernate.Type.EntityType.ResolveIdentifier
(System.Object, NHibernate.Engine.ISessionImplementor)
096fd038 06973f65 NHibernate.Type.EntityType.ResolveIdentifier
(System.Object, NHibernate.Engine.ISessionImplementor, System.Object)
096fd054 0697646b NHibernate.Engine.TwoPhaseLoad.InitializeEntity
(System.Object, Boolean, NHibernate.Engine.ISessionImplementor,
NHibernate.Event.PreLoadEvent, NHibernate.Event.PostLoadEvent)
096fd0d0 06976272
NHibernate.Loader.Loader.InitializeEntitiesAndCollections
(System.Collections.IList, System.Object,
NHibernate.Engine.ISessionImplementor, Boolean)
096fd104 064ccfe1 NHibernate.Loader.Loader.DoQuery
(NHibernate.Engine.ISessionImplementor,
NHibernate.Engine.QueryParameters, Boolean)
096fd174 064ccc17
NHibernate.Loader.Loader.DoQueryAndInitializeNonLazyCollections
(NHibernate.Engine.ISessionImplementor,
NHibernate.Engine.QueryParameters, Boolean)
096fd1ac 06dc8c17 NHibernate.Loader.Loader.LoadEntity
(NHibernate.Engine.ISessionImplementor, System.Object,
NHibernate.Type.IType, System.Object, System.String, System.Object,
NHibernate.Persister.Entity.IEntityPersister)
096fd1f8 06dc8a5a NHibernate.Loader.Entity.AbstractEntityLoader.Load
(NHibernate.Engine.ISessionImplementor, System.Object, System.Object,
System.Object)
096fd218 06dc8a23 NHibernate.Loader.Entity.AbstractEntityLoader.Load
(System.Object, System.Object, NHibernate.Engine.ISessionImplementor)
096fd228 06dc88d0
NHibernate.Persister.Entity.AbstractEntityPersister.Load
(System.Object, System.Object, NHibernate.LockMode,
NHibernate.Engine.ISessionImplementor)
096fd24c 06dc87de
NHibernate.Event.Default.DefaultLoadEventListener.LoadFromDatasource
(NHibernate.Event.LoadEvent,
NHibernate.Persister.Entity.IEntityPersister,
NHibernate.Engine.EntityKey, NHibernate.Event.LoadType)
096fd27c 06974e9d
NHibernate.Event.Default.DefaultLoadEventListener.DoLoad
(NHibernate.Event.LoadEvent,
NHibernate.Persister.Entity.IEntityPersister,
NHibernate.Engine.EntityKey, NHibernate.Event.LoadType)
096fd2b4 06974b77
NHibernate.Event.Default.DefaultLoadEventListener.Load
(NHibernate.Event.LoadEvent,
NHibernate.Persister.Entity.IEntityPersister,
NHibernate.Engine.EntityKey, NHibernate.Event.LoadType)
096fd2dc 06974a9b
NHibernate.Event.Default.DefaultLoadEventListener.ProxyOrLoad
(NHibernate.Event.LoadEvent,
NHibernate.Persister.Entity.IEntityPersister,
NHibernate.Engine.EntityKey, NHibernate.Event.LoadType)
096fd30c 0697485b
NHibernate.Event.Default.DefaultLoadEventListener.OnLoad
(NHibernate.Event.LoadEvent, NHibernate.Event.LoadType)
096fd348 069746da NHibernate.Impl.SessionImpl.FireLoad
(NHibernate.Event.LoadEvent, NHibernate.Event.LoadType)
096fd360 06dc8500 NHibernate.Impl.SessionImpl.Get(System.String,
System.Object)
096fd398 06dc848d NHibernate.Impl.SessionImpl.Get(System.Type,
System.Object)
096fd3a8 06dc7d9f Castle.ActiveRecord.ActiveRecordBase.FindByPrimaryKey
(System.Type, System.Object, Boolean)
096fd3f8 06dc7cfe Castle.ActiveRecord.ActiveRecordMediator`1
[[System.__Canon, mscorlib]].FindByPrimaryKey(System.Object, Boolean)
...my code here...
096fd76c 06980981 DynamicClass.lambda_method
(System.Runtime.CompilerServices.ExecutionScope,
System.Web.Mvc.ControllerBase, System.Object[])
096fd778 036cad22 System.Web.Mvc.ActionMethodDispatcher.Execute
(System.Web.Mvc.ControllerBase, System.Object[])
096fd784 036ca8c0
System.Web.Mvc.ControllerActionInvoker.InvokeActionMethod
(System.Reflection.MethodInfo,
System.Collections.Generic.IDictionary`2<System.String,System.Object>)
096fd7a4 036ca7d8 System.Web.Mvc.ControllerActionInvoker
+<>c__DisplayClassc.<InvokeActionMethodWithFilters>b__9()
096fd7b8 036ca6c0
System.Web.Mvc.ControllerActionInvoker.InvokeActionMethodFilter
(System.Web.Mvc.IActionFilter, System.Web.Mvc.ActionExecutingContext,
System.Func`1<System.Web.Mvc.ActionExecutedContext>)
096fd7f4 036ca62d System.Web.Mvc.ControllerActionInvoker
+<>c__DisplayClassc
+<>c__DisplayClasse.<InvokeActionMethodWithFilters>b__b()
096fd7fc 036ca6c0
System.Web.Mvc.ControllerActionInvoker.InvokeActionMethodFilter
(System.Web.Mvc.IActionFilter, System.Web.Mvc.ActionExecutingContext,
System.Func`1<System.Web.Mvc.ActionExecutedContext>)
096fd838 036ca62d System.Web.Mvc.ControllerActionInvoker
+<>c__DisplayClassc
+<>c__DisplayClasse.<InvokeActionMethodWithFilters>b__b()
096fd840 036ca6c0
System.Web.Mvc.ControllerActionInvoker.InvokeActionMethodFilter
(System.Web.Mvc.IActionFilter, System.Web.Mvc.ActionExecutingContext,
System.Func`1<System.Web.Mvc.ActionExecutedContext>)
096fd87c 036ca62d System.Web.Mvc.ControllerActionInvoker
+<>c__DisplayClassc
+<>c__DisplayClasse.<InvokeActionMethodWithFilters>b__b()
096fd884 036ca6c0
System.Web.Mvc.ControllerActionInvoker.InvokeActionMethodFilter
(System.Web.Mvc.IActionFilter, System.Web.Mvc.ActionExecutingContext,
System.Func`1<System.Web.Mvc.ActionExecutedContext>)
096fd8c0 036ca62d System.Web.Mvc.ControllerActionInvoker
+<>c__DisplayClassc
+<>c__DisplayClasse.<InvokeActionMethodWithFilters>b__b()
096fd8c8 036ca4b2
System.Web.Mvc.ControllerActionInvoker.InvokeActionMethodWithFilters
(System.Reflection.MethodInfo,
System.Collections.Generic.IDictionary`2<System.String,System.Object>,
System.Collections.Generic.IList`1<System.Web.Mvc.IActionFilter>)
096fd8e8 036c9401 System.Web.Mvc.ControllerActionInvoker.InvokeAction
(System.Web.Mvc.ControllerContext, System.String)
096fd92c 036c8e91 System.Web.Mvc.Controller.ExecuteCore()
096fd958 036c8be8 System.Web.Mvc.ControllerBase.Execute
(System.Web.Routing.RequestContext)
096fd964 036c8bb8
System.Web.Mvc.ControllerBase.System.Web.Mvc.IController.Execute
(System.Web.Routing.RequestContext)
096fd96c 036c7fac System.Web.Mvc.MvcHandler.ProcessRequest
(System.Web.HttpContextBase)
096fd9ac 036c7f28 System.Web.Mvc.MvcHandler.ProcessRequest
(System.Web.HttpContext)
096fd9c0 036c7ee8
System.Web.Mvc.MvcHandler.System.Web.IHttpHandler.ProcessRequest
(System.Web.HttpContext)
096fd9c8 660ad8f6 System.Web.HttpApplication
+CallHandlerExecutionStep.System.Web.HttpApplication.IExecutionStep.Execute
()
096fd9fc 6608132c System.Web.HttpApplication.ExecuteStep
(IExecutionStep, Boolean ByRef)
096fda3c 6608c3a3 System.Web.HttpApplication
+ApplicationStepManager.ResumeSteps(System.Exception)
096fda8c 660808ac
System.Web.HttpApplication.System.Web.IHttpAsyncHandler.BeginProcessRequest
(System.Web.HttpContext, System.AsyncCallback, System.Object)
096fdaa8 66083e1c System.Web.HttpRuntime.ProcessRequestInternal
(System.Web.HttpWorkerRequest)
096fdadc 66083ac3 System.Web.HttpRuntime.ProcessRequestNoDemand
(System.Web.HttpWorkerRequest)
096fdaec 66654d17 System.Web.HttpRuntime.ProcessRequest
(System.Web.HttpWorkerRequest)
096fdb00 036c37a9 Microsoft.VisualStudio.WebHost.Request.Process()
096fdb18 036c344e Microsoft.VisualStudio.WebHost.Host.ProcessRequest
(Microsoft.VisualStudio.WebHost.Connection)
096fdd64 79e71b4c [GCFrame: 096fdd64]
096fdd80 79e71b4c [GCFrame: 096fdd80]
096fdef4 79e71b4c [ContextTransitionFrame: 096fdef4]
096fdfe8 79e71b4c [GCFrame: 096fdfe8]
096fdfcc 79e71b4c [GCFrame: 096fdfcc]
096ff24c 79e71b4c [CustomGCFrame: 096ff24c]
096ff260 79e71b4c [CustomGCFrame: 096ff260]
096ff274 79e71b4c [CustomGCFrame: 096ff274]
096ff288 79e71b4c [CustomGCFrame: 096ff288]
096ff29c 79e71b4c [CustomGCFrame: 096ff29c]
096ff2b0 79e71b4c [CustomGCFrame: 096ff2b0]
096ff2c4 79e71b4c [CustomGCFrame: 096ff2c4]
096ff690 79e71b4c [TPMethodFrame: 096ff690]
Microsoft.VisualStudio.WebHost.Host.ProcessRequest
(Microsoft.VisualStudio.WebHost.Connection)
096ff6a0 036c2775 Microsoft.VisualStudio.WebHost.Server.OnSocketAccept
(System.Object)
096ff6b4 792c9dff
System.Threading._ThreadPoolWaitCallback.WaitCallback_Context
(System.Object)
096ff6bc 792e019f System.Threading.ExecutionContext.Run
(System.Threading.ExecutionContext, System.Threading.ContextCallback,
System.Object)
096ff6d4 792ca363
System.Threading._ThreadPoolWaitCallback.PerformWaitCallbackInternal
(System.Threading._ThreadPoolWaitCallback)
096ff6e8 792ca1f9
System.Threading._ThreadPoolWaitCallback.PerformWaitCallback
(System.Object)
096ff878 79e71b4c [GCFrame: 096ff878]

Hope this helps,
Thanks

On Jan 7, 1:16 pm, "Ayende Rahien" <aye...@ayende.com> wrote:
> Can you break into cassini when it is hanging and produce the stack traces?
>

[Yuriy Ostapenko]

I've inspected changes in ClassProxyGenerator and my guess is that new
SlimReaderWriterLock.EnterWriteLock() is not equivalent to what
ReaderWriterLock.UpgradeToWriterLock(-1) used to do.

Thanks

> 096ff274 79e71b4c ...
>
> read more »

[Yuriy Ostapenko]

Now found it.
ModuleScope.cs, line 152

> ...
>
> read more »

[hammett]

News on this one. The mef dev lead (kevin) kindly took a look at this
one and spot the same thing.

It needs to be either ExitRead followed by a EnterWrite, or
UpgradeToWrite lock. He also suggested using wrappers so it wont bite
us again:


using (new ReadLock(_lock))
{
foundProxy = _proxies.TryGetValue(viewType, out proxyType);
}

// No factory exists
if(!foundProxy)
{
// Try again under a write lock if still none generate the proxy
using (new WriteLock(_lock))
{
foundProxy = _proxies.TryGetValue(viewType, out proxyType);

if (!foundProxy)
{
proxyType = GenerateInterfaceViewProxyType(viewType);
Assumes.NotNull(proxyType);

_proxies.Add(viewType, proxyType);
}
}
}
return proxyType;

[josh robb]

Wow - thats a _really_ nice idea.

j.

[Yuriy Ostapenko]

Sounds good,
What about fixing that typo in ModuleScope.cs, line 152 for now so
people unaware of this thread don't get hit by the bug?
It still says EnterWriteLock() while obviously has to be ExitWriteLock
() and is the actual reason for deadlocks.

Thanks,

> ...
>
> read more »

[paszczi]

On Jan 3, 9:18 pm, hammett <hamm...@gmail.com> wrote:
> Applied. Thanks
>

Hi!

I'm extensively using Castle stack in my project (MicoKernel, Windsor
and ActiveRecord). My software runs on both mono and .net framework.
After applying this patch, I'm no longer able to use Castle.Windsor.
The reason is that InternalsHelper class in DynamicProxy now relies on
SlimReaderWriterLock which then uses ReaderWriterLockSlim. This class
is implemented on trunk version of mono (2.2) but is doesn't support
any LockRecursionPolicy different than noRecursion. I'm not sure
whether Castle is aimed to be mono compilant but this little change
made it unusable on mono. Is there any chance of changing this or
should we just wait for mono being updated?

Cheers,
Maciej Paszta

[hammett]

I'd suggest use a previous trunk version and ping the mono developers
to implement the lacking features.

[hammett]

Good catch. But I'll bet it's another source of problems, not the sole
one. I'll fix all the points today.

[Krzysztof Koźmic]

These changes were made as a result of moving Castle Stack to .net 3.5.
If you need to maintain Mono compatibility, I'd suggest use last release .net-2.0-compatibile (it's a tag in the repository).
How important is it for you to run on the trunk?
Are you using any recently (within last month) added features?

Cheers,

Krzysztof

paszczi pisze:

[Maciej Paszta]

On Jan 10, 2009, at 9:37 AM, Krzysztof Koźmic wrote:

> These changes were made as a result of moving Castle Stack to .net
> 3.5.
> If you need to maintain Mono compatibility, I'd suggest use last
> release .net-2.0-compatibile (it's a tag in the repository).
> How important is it for you to run on the trunk?
> Are you using any recently (within last month) added features?

Actually we are migrating from RC3 to something new (this was caused
by an errors that sometimes occurred when processing nhibernate
queries) so we are actually not depending on any new functionality so
we can always stick to older revision :)
--
Maciej Paszta

[Maciej Paszta]

Krzysztof Koźmic wrote:
> These changes were made as a result of moving Castle Stack to .net 3.5.
> If you need to maintain Mono compatibility, I'd suggest use last
> release .net-2.0-compatibile (it's a tag in the repository).
> How important is it for you to run on the trunk?
> Are you using any recently (within last month) added features?

Is LockRecursionPolicy really necessary here? I'm aware that
ReaderWriterLockSlim is better than it's predecessor but according to
msdn LockRecursionPolicy.SupportsReccursion is not recommended for a
new code ("it introduces unnecessary complications and makes your code
more prone to deadlocks"). So maybe it's better to use standard policy
(no recursion) and introduce safer code, instead of hanging to old
behavior (SupportsRecursion makes ReaderWrtierLockSlim work like a
ReaderWriterLock)?

Link to MSDN:
http://msdn.microsoft.com/en-us/library/system.threading.readerwriterlockslim.aspx
<http://msdn.microsoft.com/en-us/library/system.threading.lockrecursionpolicy.supportsrecursion.aspx>

[Krzysztof Koźmic]

Yeah, you may be right.

There are many places in DP code that need refactoring. It's just that
the code works (most of the time) so there's no push on doing the
refactoring.
If you'd like to investigate the issue feel free to provide a patch :)

Krzysztof

Maciej Paszta pisze:

[hammett]

Check the code, it's not using 'supports recursion' anymore.

--
Cheers,
hammett
http://hammett.castleproject.org/

[Maciej Paszta]

hammett wrote:
> Check the code, it's not using 'supports recursion' anymore.
>

Yep, works like a charm :)

[Staxxx]

Is the reason the silverlight version is now not building -- due to the fact it's not in the integrated build?

[Jonathon Rossi]

Is the reason the silverlight version is now not building -- due to the fact it's not in the integrated build?

 

Yes.