[Mono-list] External pthread delegate call
Jerome Laban
jayly@hotmail.com
Sun, 19 Jan 2003 11:45:45 +0100
This is a multi-part message in MIME format.
------=_NextPart_000_0257_01C2BFB0.4D448280
Content-Type: text/plain;
charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable
Hi,
I am trying to implement a UPnP IGD (Internet Gateway Device) compilant =
daemon using mono and the UPnP SDK from Intel.
This SDK is using internal threading using pthreads an notifies the host =
application of events through a registered C style callback.
Every thing goes fine until the delegate is called from this internally =
created thread. The program crashes with unhandled exception. I've =
compiled the UPnP SDK using <gc/gc.h> to allow the GC to intecept the =
calls to pthreads primitives, but this seems not to be enough.
After a small investigation, I've discovered that the method =
mono_get_domain is called from mono_jit_compile_method. All this is =
directly called from a thread that has not been created the mono =
runtine, thus not having any TLS containing the original domain.
The method mono_get_domain returns a NULL pointer that causes the line :
(jit.c:3815) jit_code_hash =3D target_domain->jit_code_hash;
to dereference a NULL pointer.
Am I missing something ? Should the mono runtime also intercept any =
pthreads calls and how can this be done ?
Anyway, so far this is the only problem that prevents this SDK from =
running from a mono hosted application.=20
Thanks,
Jerome
------=_NextPart_000_0257_01C2BFB0.4D448280
Content-Type: text/html;
charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Dwindows-1252">
<META content=3D"MSHTML 6.00.2800.1126" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY>
<DIV><FONT size=3D2>Hi,</FONT></DIV>
<DIV><FONT size=3D2></FONT> </DIV>
<DIV><FONT size=3D2>I am trying to implement a UPnP IGD (Internet =
Gateway=20
Device) compilant daemon using mono and the UPnP SDK from=20
Intel.</FONT></DIV>
<DIV><FONT size=3D2>This SDK is using internal threading using pthreads =
an=20
notifies the host application of events through a registered C=20
style callback.</FONT></DIV>
<DIV><FONT size=3D2></FONT> </DIV>
<DIV><FONT size=3D2>Every thing goes fine until the delegate is called =
from this=20
internally created thread. The program crashes with=20
unhandled exception. I've compiled the UPnP SDK using <FONT=20
face=3D"Courier New"><gc/gc.h></FONT> to allow the GC to intecept =
the calls=20
to <FONT face=3D"Courier New">pthreads</FONT> primitives, but this seems =
not to be=20
enough.</FONT></DIV>
<DIV><FONT size=3D2></FONT> </DIV>
<DIV><FONT size=3D2>After a small investigation, I've discovered that =
the method=20
<FONT face=3D"Courier New">mono_get_domain</FONT> is called from <FONT=20
face=3D"Courier New">mono_jit_compile_method</FONT>. All =
this is=20
directly called from a thread that has not been created the mono =
runtine, thus=20
not having any TLS containing the original domain.</FONT></DIV>
<DIV><FONT size=3D2></FONT> </DIV>
<DIV><FONT size=3D2>The method <FONT face=3D"Courier =
New">mono_get_domain</FONT>=20
returns a NULL pointer that causes the line :</FONT></DIV>
<DIV><FONT size=3D2></FONT> </DIV>
<DIV><FONT size=3D2> <FONT face=3D"Courier New"> =
(jit.c:3815)=20
jit_code_hash =3D =
target_domain->jit_code_hash;</FONT></FONT></DIV>
<DIV><FONT size=3D2></FONT> </DIV>
<DIV><FONT size=3D2>to dereference a NULL pointer.</FONT></DIV>
<DIV><FONT size=3D2></FONT> </DIV>
<DIV><FONT size=3D2>Am I missing something ? Should the mono runtime =
also=20
intercept any pthreads calls and how can this be =
done ?</FONT></DIV>
<DIV><FONT size=3D2></FONT> </DIV>
<DIV><FONT size=3D2>Anyway, so far this is the only problem that =
prevents this SDK=20
from running from a mono hosted application. </FONT></DIV>
<DIV><FONT size=3D2></FONT> </DIV>
<DIV><FONT size=3D2></FONT> </DIV>
<DIV><FONT size=3D2>Thanks,</FONT></DIV>
<DIV><FONT size=3D2>Jerome</FONT></DIV></BODY></HTML>
------=_NextPart_000_0257_01C2BFB0.4D448280--