[Mono-bugs] [Bug 74879][Wis] New - Need to have a consistent initialization sequence

[bugzilla-daemon@bugzilla.ximian.com]

Please do not reply to this email- if you want to comment on the bug, go to the
URL shown below and enter your comments there.

Changed by gkodinov@openlinksw.co.uk.

http://bugzilla.ximian.com/show_bug.cgi?id=74879

--- shadow/74879	2005-05-09 07:22:49.000000000 -0400
+++ shadow/74879.tmp.4385	2005-05-09 07:22:49.000000000 -0400
@@ -0,0 +1,40 @@
+Bug#: 74879
+Product: Mono: Runtime
+Version: unspecified
+OS: All
+OS Details: 
+Status: NEW   
+Resolution: 
+Severity: Unknown
+Priority: Wishlist
+Component: misc
+AssignedTo: mono-bugs@ximian.com                            
+ReportedBy: gkodinov@openlinksw.co.uk               
+QAContact: mono-bugs@ximian.com
+TargetMilestone: ---
+URL: 
+Summary: Need to have a consistent initialization sequence
+
+I'm trying to maintain the mono hosting in Virtuoso
+(http://www.openlinksw.com/virtuoso). 
+
+What I basically need is :
+
+1. Be able to initialize the Mono runtime in a consistent (across releases)
+sequence (and not call a Main () function of some assembly in order to do
+that).
+2. Be able to associate (and disassociate) native threads to Mono so that
+they can run Mono code. Then reuse such initialized thread (with a
+different number of Virtuoso stack frames each time).
+3. Be able to call arbitrary Mono managed code functions passing/receiving
+all the datatypes in a platform and release independent manner.
+
+I have been solving the above by maintaining a custom patched version of
+the Mono runtime (and having Virtuoso to link statically to it) for each
+supported OS/C library configuration. This is easily becoming a substantial
+logistical burden. So I'm looking for a way to lessen it.
+
+My question is :
+how to make the Mono runtime hosting API as easy to the developer as the
+MS.NET one is  (and flexible enough to cope the above IMHO typical usage
+cases) ?