On Aug 25, 2014, at 2:05 PM, Neale Ferguson nealefergu...@verizon.net wrote:
Do you mean mine not having protected virtual?
Dispose(bool) doesn't need to be `protected virtual` unless you plan on
supporting inheritance.
Rephrased: if your type is sealed, it doesn't need to be `protected
Yeah, it is a sealed class which is why I didn't do protected virtual, so I'm
wondering to what your initial remark referred: Idiomatic IDisposable
implementation is slightly different from what you have.
On Aug 26, 2014, at 1:09 AM, Jonathan Pryor jonpr...@vt.edu wrote:
On Aug 25, 2014, at
I implemented a Dispose method for OracleParameter:
~OracleParameter ()
{
Dispose(false);
}
public void Dispose ()
{
Dispose (true);
}
Are you explicitly calling dispose? Finalizers May not have been run yet
depending on gc etc
On Monday, August 25, 2014, Neale Ferguson nealefergu...@verizon.net
wrote:
I implemented a Dispose method for OracleParameter:
~OracleParameter ()
{
Finalization is not deterministic, it depends on the GC been able to
collect all related objects.
Maybe you have things keeping some of those 700 objects around?
The way I test those things in a way that is reasonably reliable is:
var t = new Thread (myTest);
t.Start ();
t.Join ();
GC.Collect
Do you mean mine not having protected virtual?
On Aug 25, 2014, at 2:00 PM, Jonathan Pryor jonpr...@vt.edu wrote:
Idiomatic IDisposable implementation is slightly different from what you have:
http://msdn.microsoft.com/en-us/library/system.idisposable(v=vs.110).aspx
Idiomatic IDisposable implementation is slightly different from what you have:
http://msdn.microsoft.com/en-us/library/system.idisposable(v=vs.110).aspx
On Aug 25, 2014, at 11:08 AM, Neale Ferguson nealefergu...@verizon.net wrote:
I implemented a Dispose method for OracleParameter:
I am also wondering about the parameters in some of the OCIBind methods and
the OCIDefineByPosPtr that are ref IntPtr. There's a small window when GC
could suspend the thread where the IntPtr object is also moved before the OCI
call has completed and set the underlying IntPtr field.
On Aug
yeah, that makes sense.
On Fri, Aug 22, 2014 at 9:45 AM, Neale Ferguson nealefergu...@verizon.net
wrote:
I am also wondering about the parameters in some of the OCIBind
methods and the OCIDefineByPosPtr that are ref IntPtr. There's a small
window when GC could suspend the thread where
Mono does conservative scanning of the native stack, so once the pointer
has crossed over to native, the containing object will remain pinned.
On Fri, Aug 22, 2014 at 9:45 AM, Neale Ferguson nealefergu...@verizon.net
wrote:
I am also wondering about the parameters in some of the OCIBind
Is that just a comment on my ref IntPtr question or the use of ref with the
OCI stuff in general?
On Aug 22, 2014, at 10:45 AM, Rodrigo Kumpera kump...@gmail.com wrote:
Mono does conservative scanning of the native stack, so once the pointer has
crossed over to native, the containing
Hey Neale,
You can safely pass interior pointers to pinvoke without fearing the object
been collected for the duration of the call.
Mind that you have to correctly use specify in/out/ref depending on the
copy semantics you need.
Problems only arise when native keeps that pointer after the call
Thanks. I've made changes to OciDefineHandle and have cured nearly all the
failures I had been experiencing. I have started on OracleParameter as it has
an object called indicator that is used by the OCIBindxxx calls and appears to
suffer from the same problem. I was allocating the object in
I've been looking at OciDefineHandle and the OciDefineByPos call it uses in
particular. Currently two of the parameters passed to this call are short
variables. They are passed as ref fields as Oracle uses their address to put
size and indicator data once the data is fetched. However, being
Hey Neale,
What makes a short ref suitable to be moved during GC?
I am confused, I thought we wouldn't do that.
Miguel
On Thu, Aug 21, 2014 at 6:58 PM, Neale Ferguson nealefergu...@verizon.net
wrote:
I've been looking at OciDefineHandle and the OciDefineByPos call it uses
in particular.
Hello,
Wanted to follow up to Neale's comment, as he clarified an important point
that I overlooked.
There are two ref parameters that are being passed to unmanaged code, both
point to fields inside the OciDefineHandle managed type.
Neale's analysis is correct: the object might move and with
16 matches
Mail list logo
