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 de
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
wrote:
> I've been looking at OciDefineHandle and the OciDefineByPos call it uses
> in particular. Currently two of the param
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 it,
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 Au
yeah, that makes sense.
On Fri, Aug 22, 2014 at 9:45 AM, Neale Ferguson
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 the IntPtr object is al
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
wrote:
> I am also wondering about the parameters in some of the OCIBind
> methods and the OCIDefi
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 wrote:
> Mono does conservative scanning of the native stack, so once the pointer has
> crossed over to native, the containing object will remain
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 fi
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 nat
I implemented a Dispose method for OracleParameter:
~OracleParameter ()
{
Dispose(false);
}
public void Dispose ()
{
Dispose (true);
}
v
Are you explicitly calling dispose? Finalizers May not have been run yet
depending on gc etc
On Monday, August 25, 2014, Neale Ferguson
wrote:
> I implemented a Dispose method for OracleParameter:
>
> ~OracleParameter ()
> {
> Dispose(false
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 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 wrote:
> I implemented a Dispose method for OracleParameter:
>
>~OracleP
On Aug 25, 2014, at 2:05 PM, Neale Ferguson 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 virtual`.
If your type *isn't
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 wrote:
> On Aug 25, 2014, at 2:05 PM, Neal
16 matches
Mail list logo