[Mono-dev] csproj or sln to Makefile?
Has anyone worked on a csproj or sln to Makefile converter/xslt that works with gmcs and .Net 2.0? I know there was one built a few years ago. We are currently using Microsoft's compiler to build our assemblies, but there are some advantages to using gmcs (the most important being debug symbols). Thanks, JD ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
RE: [Mono-dev] Application performance benchmarking
I'm not aware of any profiling software for running under the Mono runtime. Microsoft ships a fairly limited one with VS 2005 Team Edition that requires you to use their testing infrastructure. We use Compuware's DevPartner Profiler for all our profiling. It has been extremely valuable. -JD Conley On Tuesday 21 March 2006 11:51, Lukas Lipka wrote: Hi, Does anyone know what is the best way to benchmark a C# app? I'm specifically looking for something, that would tell me which part of the code takes up lot of time, how long does a specific block of code take to execute, etc. I don't have a direct answer, but just to help you in your googling, what you're looking for is profiling software. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
RE: [Mono-dev] Issue Compiling on Red Hat Linux
Id guess this is the problem: string sysdate = (string)dbreader[sysdate]; Use dbreader[sysdate].ToString() or Convert.ToString(dbreader[sysdate]). If sysdate was a Date value in your DB it wont directly cast to a string. You need to do a conversion. -JD Conley From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Javier Ruiz Sent: Friday, February 10, 2006 3:23 PM To: 'Jonel Rienton'; mono-devel-list@lists.ximian.com Subject: RE: [Mono-dev] Issue Compiling on Red Hat Linux That would help sorry here is the code. From: Jonel Rienton [mailto:[EMAIL PROTECTED] Sent: Friday, February 10, 2006 4:20 PM To: 'Javier Ruiz'; mono-devel-list@lists.ximian.com Subject: RE: [Mono-dev] Issue Compiling on Red Hat Linux hard to help without seeing any code From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Javier Ruiz Sent: Friday, February 10, 2006 4:08 PM To: mono-devel-list@lists.ximian.com Subject: [Mono-dev] Issue Compiling on Red Hat Linux I'm running mono and I compile my program ok but when I run the program I get the following error. I can run the program on windows with no problems. ERROR: Unhandled Exception: System.InvalidCastExeception: Cannot cast from source type to destination type. Javier Ruiz Oracle DBA -- No virus found in this incoming message. Checked by AVG Free Edition. Version: 7.1.375 / Virus Database: 267.15.4/255 - Release Date: 2/9/2006 ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
RE: [Mono-dev] Ldap and Threading
As I wrote in my analysis of your patches, I ran the application you provided and, unfortunately, did not repro the issue. (see http://lists.ximian.com/pipermail/mono-devel-list/2006-January/016771.ht ml). It didn't work reliably. Now it does. Our intentions are good. Search for me on this list. I did some similar (very large) patches to Mono.Security that are working quite well. Run your test suite if you're worried about introducing bugs into the library. Please, just take the patch! I don't want to maintain my own copy of this library. Threading bugs are notoriously difficult to reproduce. If I remember correctly (Again, I submitted this way back in August -- with only the necessities patched), the issue was more easily reproduced on a slower network connection where search results trickled in a bit more. The background thread that parses the network data was adding results into the collection while I was pulling them out from my thread. I was testing over a VPN with about 30ms ping latency with the 2.0 build. -JD ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
RE: [Mono-dev] Ldap and Threading
2. The rest of the patch deals with correct catching and passing of the exceptions thrown in the working thread to the user thread. This definitely solves the hang issue, but does nothing with the cause of those exceptions. So the route bug(s) remain (correct me if I'm wrong). I believe you are correct to the limits of my understanding, but I do see some changes in the MessageAgent.cs and MessageVector.cs classes that are locking related. Mostly around using the collections SyncRoot instead of the collection object itself for the lock. My assumption when I reviewed the code was that these changes provided a more reliable lock on the collection and as such prevented the race when accessing the returned messages. I used the SycRoot so that I could cleanly use a synchronized internal list in MessageVector and still have critical sections around loops. This was very important. One of the exceptions was caused due to that collection being changed by an add or remove operation while another thread was doing a loop. For better understanding of relevant changes I found my original patch to the Novell library. It's attached. Again, this was to the previous version of the lib, so you shouldn't apply it directly any current tree. I submitted this in August and started some threads here about getting it integrated, but that went nowhere. Here's the link to the Novell Forge item: http://forge.novell.com/modules/xfmod/tracker/index.php?func=detailaid= 1271group_id=1318atid=1364 To summarize, most of the relevant changes were for better background error handling, moving around critical sections slightly to fix some race conditions, and properly synchronizing the MessageVector collection. -JD Conley jd-ldap.diff Description: jd-ldap.diff ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
RE: [Mono-dev] Ldap and Threading
If you can send to this forum just the relevant diffs (patches) and, if possible, provide a brief explanation about the changes, I will be glad to look into them. Ok I've included two different patches. The Full_Novell one is a complete diff based on the code that JD provided to me, so that you can have a base of what was provided to me. The second BoiledDown patch contains what I'm fairly certain are the relevant fixes (If I wasn't sure I used JD's changes). Yes, most of the changes centered around thread synchronization issues I ran into and exception handling. I did also clean up some things I noticed while I was in there. If more detailed explanations are needed I'm afraid we'll have to hope that JD is still reading the list and can respond. Yup, I'm still listening. Thanks for putting this together Mike. I had submitted a patch to the Novell LDAP project and apparently it never got rolled in anywhere. There may also be some discrepancy in the version used to do the diff. The code I sent you was based on the Novell release version 2.1.3 at the time (August). I see they're up to 2.1.4 now. -JD Conley ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] Compile npgsql?
Does the PostgreSQL provider (npgsql) that ships with the Mono Windows build work under MS.NET as well as Mono, or will we need to compile it from source under MS.NET? -JD ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
RE: [Mono-dev] Compile npgsql?
If you need Npgsql for ms.net you can get it from Npgsql project site: http://gborg.postgresql.org/project/npgsql We're actually working with MS.NET 2.0 Beta 2, for which builds aren't present on the Npgsql site that I can see. -JD ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
RE: [Mono-dev] Re: [PATCH] Fully Asynchronous and Re-Factored SslStreams in Mono.Security
Harry,
The latest patch that I sent to the
maintainers doesnt use the delegate BeginInvoke any more. It uses an
asynchronous BeginRead or BeginWrite call to the innerStream to kick off the
handshake in a background thread.
-JD Conley
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Harry Holt
Sent: Wednesday, August 31, 2005
6:12 AM
To:
mono-devel-list@lists.ximian.com
Subject: Re: [Mono-dev] Re:
[PATCH] Fully Asynchronous and Re-Factored SslStreams in Mono.Security
This seems to work fine
on W2k. Running under IIS5.1 on WXP, though, it always throws an
ObjectDisposedException in SSLStreamBase.cs when a bind
over SSL is attempted.
Won't this:
if (workthreads =
(maxworkthreads - 4))
{
async = false;
}
cause the SSL Stream to use synchronous handshake until threads start getting
used?
I would also recommend changing this:
protected void checkDisposed()
{
if (this.disposed)
{
throw new ObjectDisposedException(The Stream is closed.);
}
}
to this:
protected void checkDisposed()
{
if (this.disposed)
{
throw new ObjectDisposedException(this.GetType().Name, The Stream is
closed.);
}
}
which produces a more readable error message.
Thx... HH
On 8/25/05, Sebastien
Pouliot [EMAIL PROTECTED]
wrote:
Hello JD,
On Wed, 2005-24-08 at 21:12 -0700, JD Conley
wrote:
I took the plunge and fully implemented async Ssl streams for both
client and server.This fixes
http://bugzilla.ximian.com/show_bug.cgi?id=75687
as well as other bugs
I've been talking with Sebastien and Carlos about off list. This patch
passes the SocketHell tests that I contributed to them last week
(multi threaded concurrent async streaming through TCP sockets).
Wow! That's the kind of surprise I like when I wake up :-)
It's also a bit of a re-factor, though I only touched two classes and
added one.I pulled most of the code out of the individual
SslClientStream and SslServerStream and moved it down into a new
abstract SslStreamBase.Client and server are now practically
the
same implementation.I left all existing interfaces present,
but
obviously had to add some new ones.
We always sticked to the Fx 1.2 preview specs for the Ssl[Client|
Server]Stream API and didn't planned to change this before implementing
the new SslStream (in System.dll) for 2.0 - BUT this isn't a major
problem if it doesn't break binary compatibility (for current
applications linked with Mono.Security.dll).
The only gotcha is if you start running low on threadpool
threads.
Then the Ssl Stream will fall back to a synchronous handshake. The
other option here is to spawn a thread ourselves for the handshake
instead of using Delegate.BeginInvoke(), use the IO ThreadPool (is
that available to Mono.Security?), or just live with a synchronous
handshake. Of course, 99.999% of the time this issue won't occur and
won't be a problem unless you have both client and server sharing the
same Threadpool causing a deadlock.
That's not worse than the original (where the handshake was always
synchronous).
I hope this helps and gets integrated.It's definitely
necessary for
our implementation.
1. I'll review the patch and, in doing so, check for possible binary
compatibility problems. I'm sure Carlos will do likewise;
2. I'll make public a new Mono.Security.dll assembly so that people that
depends on Ssl*Stream may tests it and report any problem/difference;
3. I'll run the regressions tests, the tools under /mcs/class/
Mono.Security/Test/tools/*, to see if it works in previously reported
conditions.
4. Commit (both the patch and your SocketHell tests). Hopefully we can
do all this before the next release.
Many thanks!
--
Sebastien
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
--
Robbie the Nanobot says:
Only YOU can prevent gray goo
(NEVER release nanobot assemblers without replication limiting code)
http://lizardslounge.org
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
RE: [Mono-dev] Fatal Error In GC: Too Many Threads
The default in the GC for windows is to use 256 threads MAX. We should increase this. Now, the fact that you have 200+ threads running: is that by design in your app or is that a bug in itself? Is there any way I can adjust this value using an environment variable or an API somewhere? -JD Conley ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
RE: [Mono-dev] Re: [PATCH] Fully Asynchronous and Re-Factored SslStreams in Mono.Security
I am unable to compile this, though, as I am getting CLS-compliance errors. The Assembly is marked as compliant but the SslStreamBase class includes a read object and a Read method (differing only in case). Is it just me? I'm using VS 2003 to compile - maybe mcs doesn't check for compliance? Oh, you can make almost all of the fields private in that class. At the very least negotiate, read, and write can be private. That should fix it. :) I was compiling with VS 2005 and have that particular warning disabled. -JD ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
RE: [Mono-dev] Novell.Directory.Ldap in the Mono tree
We had asked the same answer before when we had fixes for Novell.Directory.Ldap. What is the official answer? How do we maintain sync with the Novel sources? I submitted a patch to the Novell Forge project last night, as it seems like the root project. You can view it at: http://forge.novell.com/modules/xfmod/tracker/index.php?func=detailaid= 1271group_id=1318atid=1364 -JD Conley ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
RE: [Mono-dev] Novell.Directory.Ldap in the Mono tree
I was wondering if there was any synchronization between Novell.Directory.Ldap on Novell forge and Mono. I have noticed that the trees are currently fairly different. I'm trying to make a decision on which to patch, but I don't really know. I am leaning toward patching the one on Novell forge since that seems to be the root, but then when, if ever, would my fixes show up in the Mono tree? Would I be stuck building my own version of Novell.Directory.Ldap for distribution? Is there any particular reason why I should modify the one in the Mono tree vs. the one in Novell Forge? Would you be interested in merging the changes from the official Novell build into our tree? That's certainly a possibility, but I wouldn't want to do it if it was something that was going to have to be maintained in separate branches going into the future. There really should be only one branch, maybe with separate build scripts and some defines for Mono's TARGET_JVM and anything else that's needed. -JD ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] Novell.Directory.Ldap in the Mono tree
I was wondering if there was any synchronization between Novell.Directory.Ldap on Novell forge and Mono. I have noticed that the trees are currently fairly different. I'm trying to make a decision on which to patch, but I don't really know. I am leaning toward patching the one on Novell forge since that seems to be the root, but then when, if ever, would my fixes show up in the Mono tree? Would I be stuck building my own version of Novell.Directory.Ldap for distribution? Is there any particular reason why I should modify the one in the Mono tree vs. the one in Novell Forge? -JD ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
RE: [Mono-dev] Targets file to aid in Mono development on Visual Studio 2005 Beta 2
My favorite part of this targets file is that it lets you build projects targeted at Mono class libraries (even mscorlib) and run them under the MS runtime through the VS.NET IDE. This gives you some debugging capabilities of your projects in Windows. However, as far as I know you still need to build with mcs and be in Linux if you want to debug under the Mono runtime. -JD Conley P.S. I slapped Mike around a bit for spamming you with our disclaimer and his contact info again. ;) ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] Fatal Error In GC: Too Many Threads
I get this error message box in Mono under Windows running some of the more interesting tests that I have. At the time it shows up there are 200 and some odd threads in mono.exe (which, I found this pretty funny, is less than an iexplore.exe process I have). Basically all of the threads are in Sleep/Wait. Why would I see this exception? What can I do about it? -JD Conley ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] System.DirectoryServices text encoding
I've been working with Novell.Directory and System.DirectoryServices quite a bit recently. I was wondering about the seemingly arbitrary UTF-8 encoding that is going on in there. Is UTF-8 the only Unicode text encoding used by LDAP text based attributes in the spec? -JD Conley ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] Unhandled Exceptions in Novell.Directory.Ldap and other Synchronization Issues
Novell.Directory.Ldap spawns threads for various queued operations. However, it appears as though there is no catch all exception handler in Connection+ReaderThread:Run() (or other spawned threads either). If anything other than an IO exception is thrown the thread will exit without notifying the consumer, and in Beta 2 this causes the application to terminate. In my current application it causes a search timeout. One such example is as follows (this is received some time during connecting, binding, or doing a search -- I'm not exactly sure): Unhandled Exception: System.ArgumentException: length in 0x004a3 System.Array:Copy (System.Array sourceArray, Int32 sourceIndex, System.Array destinationArray, Int32 destinationIndex, Int32 length) in 0x0004f System.Array:Copy (System.Array sourceArray, System.Array destinationArray, Int32 length) in 0x00016 System.Collections.ArrayList:CopyTo (System.Array array) in 0x0002a System.Collections.ArrayList:ToArray () in 0x0004a Novell.Directory.Ldap.MessageVector:findMessageById (Int32 msgId) in 0x001b7 Novell.Directory.Ldap.Connection+ReaderThread:Run () in (wrapper delegate-invoke) System.MulticastDelegate:invoke_void () This exception looks very strange at first glance. An invalid length on an ArrayList:ToArray() just doesn't compute. After further investigation I have found that the MessageVector class is only partially synchronized. Synchronization happens on the findMessageById() and some other functions that do iteration, but the atomic Add, Remove, and Contains operations are not protected. It appears as though the findMessageById is being called while messages are being added to or removed from the MessageVector in another thread. It is possible that I am the first to notice this since I am currently doing LDAP queries through a VPN tunnel over an internet connection. Messages coming back from the server have a tendency to trickle in relatively slowly. So, do I submit patches to this group, or through a different Novell forum? Is anybody actively working on this subsystem in such a way that we might have to merge a lot of work? -JD Conley ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] System.DirectoryServices and LdapReferralException
I'm trying to connect up to an Active Directory and run a search and I get a LdapReferralException. For example, I am running a query on the host adserver.coversant.net and while iterating through search results I get a referral exception for LDAP://coversant.net/CN=Configuration,DC=coversant,DC=net. The configuration DN does not even have nodes in it that match the filter I was searching on. I also tried to search the directory by using the Novell.Directory.Ldap classes directly and was able to reproduce the same exception. I compared the results received before the exception to the results from Microsoft's System.DirectoryServices and they were identical. Maybe Mono's System.DirectoryServices should be ignoring this referral? Any thoughts? -JD ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
RE: [Mono-dev] Novell.Directory.Ldap in 2.0
In fact, where is this (and System.DirectoryServices) in the Mono source tree so I can look into it? :) Nevermind this comment. I was looking at an old tree snapshot extracted with WinRAR which for some reason likes to screw up tar'd archives. -JD ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] Novell.Directory.Ldap in 2.0
Exceptions don't appear to work correctly in the 2.0 build of Novell.Directory.Ldap. In fact, where is this (and System.DirectoryServices) in the Mono source tree so I can look into it? :) On a related note, how do you set this library to use auto-referral (the web page says it's possible)? My Active Directory server keeps throwing me back a referral while enumerating search results and I don't want to have to manually go to it. System.ArgumentNullException: Argument cannot be null. Parameter name: value in 0x000d1 System.Threading.Thread:set_CurrentUICulture (System.Globalization.CultureInfo value) in 0x00085 Novell.Directory.Ldap.Utilclass.ResourcesHandler:getMessage (System.String messageOrKey, System.Object[] arguments, System.Globalization.CultureInfo locale) in 0xf Novell.Directory.Ldap.Utilclass.ResourcesHandler:getMessage (System.String messageOrKey, System.Object[] arguments) in 0x0009a Novell.Directory.Ldap.LdapException:getExceptionString (System.String exception) in 0x0001f Novell.Directory.Ldap.LdapReferralException:ToString () -JD Conley ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
RE: [Mono-dev] Status of SslStream and Related Classes
I'm building code that needs to run under both frameworks and right now I'm deciding between updating Mono or writing my own SslStream based on Mono.Security and using #if defs (I'd rather do the former). Mono.Security.dll already contains SslClientStream and SslServerStream classes (which were based on the MS Fx 1.2 preview API) and was done by Carlos (and a few bits by me). There are a few known bugs (mostly related to async support) but they are working, including support for client, server, SSL3, TLS1, client-side certificates ... Using them would be easier it you want SSL support on both framework (as Mono.Security.dll doesn't depend on anything Mono specific) including 1.x versions. Unless you are requiring something special/specific wrt SSL ? I will have a look at Mono.Security. Right now the code base is compiling (and mostly working) on both the MS.Net 2.0 Beta 2 and Mono 1.1.8 2.0 libraries. Tls is one of the few remaining sticking points. I don't need anything special. After I sent the original email I went ahead and ifdef'd for Mono's Beta 1 style representation of the SslStream and related naming. I got some NotImplementedException's on the SslStream.ClientAuthenticate that says 100% implemented with no TODO in HEAD (haven't looked into it yet). Hopefully it's been added since 1.1.8 release I'm running with. -JD ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] Status of SslStream and Related Classes
I was working on some System.Net.Security.SslStream based code and noticed the class status page (http://mono.ximian.com/class-status/mono-HEAD-vs-fx-2/class-status-Syst em.html) shows that the current HEAD implementation does not match the naming conventions of the Microsoft .NET libraries. I was going to go ahead and implement the correct class names and submit a patch, but before I do is there any particular reason I shouldn't? :) I'm building code that needs to run under both frameworks and right now I'm deciding between updating Mono or writing my own SslStream based on Mono.Security and using #if defs (I'd rather do the former). -JD Conley ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-devel-list] System.Runtime.Remoting Tests
I was looking into Remoting a bit and was searching for the unit tests and how the multiple application domains or contexts were handled for testing. There was one set of tests under \mono\mcs\class\corlib\Test and something under \mono\mono\tests. Can someone explain the correlation? Where are the 238 tests that are shown on the test status page? -JD Conley ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
RE: [Mono-devel-list] System.Runtime.Remoting Tests
El dt 05 de 07 del 2005 a les 16:40 -0700, en/na JD Conley va escriure: I was looking into Remoting a bit and was searching for the unit tests and how the multiple application domains or contexts were handled for testing. There was one set of tests under \mono\mcs\class\corlib\Test and something under \mono\mono\tests. Can someone explain the correlation? Where are the 238 tests that are shown on the test status page? Those tests are in mcs/class/System.Runtime.Remoting/Test. I'm looking in the latest release tarball and I can't seem to find any Test directory under System.Runtime.Remoting. In fact there is no System.Runtime.Remoting directly under mcs/class. I assume you mean the one under corlib. There are some tests in mcs/class/corlib/Test/System.Runtime.Remoting. A Find in Files of everything under the Mono tree for the tests at http://mono.ximian.com/tests/displayDetails.php?testsuite=System.Runtim e.Remotingfile=20050705status=0profile=0distro=0 does not produce any results. Is this something only in SVN that doesn't make the cut into the released build? If so, I apologize. :) -JD Conley ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
RE: [Mono-devel-list] PATCH: reworked async IO for Socket
This patch intercepts the calls before they are added to the thread pool and uses a single thread for polling on all the sockets running asynchronous read/write. Once sockets are ready, it dispatches the work item to the threadpool which will not be blocked. The patch also serializes read/write calls and allows for multiple Begin* calls on a given socket at the same time (this fails with current mono from SVN). This patch is a good start, but this is a fairly serious issue. Asynchronous IO is at the heart of high performance, scalable, network servers. Is anyone planning on integrating asynchronous sockets with IO Completion Ports (on Windows) and whatever the equivalent is on the other platforms? There has to be a faster way with some kernel level asynchronous APIs, rather than playing in user space. Of course, maybe I just misunderstood this thread. I haven't actually looked at the code that does this work. JD ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
RE: [Mono-devel-list] PATCH: reworked async IO for Socket
For windows, well, patches for using its asynch. IO functions are welcome :). We'll see... I'm not very C proficient. :) For the rest, aio_(read|write) are not always available and/or SIGEV_THREAD does not work. Even when SIGEV_THREAD works, the thread that calls the callback function will be killed if the callback takes too much time, which is not much. So we had to use another thread to actually invoke the managed callback (and the thread has to be from the threadpool, to behave like MS). The code that we have right does not have any performance issue and works on any system that have select(). And we are just 'wasting' one thread for polling on all the sockets with ongoing async. operations. Interesting. May I suggest using a different threadpool than the static application pool? With that you can manage the concurrency settings separately, and not block application thread pooling and async delegates. I believe the MS implementation uses a VERY large IOCP threadpool for this. JD ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
RE: [Mono-devel-list] PATCH: reworked async IO for Socket
The code that we have right does not have any performance issue and works on any system that have select(). And we are just 'wasting' one thread for polling on all the sockets with ongoing async. operations. I was reading about async sockets with great interest and here are my 2 cents: application that I ported to Mono uses async sockets extensively, its a crawler and it connects to sites and pulls pages for search engine, so one of users run it on Linux and he achieved throughput close to 10 Mbits without problem. That was on Mono v1.1.5, so if async sockets become faster with that new patch then things will become even better! The performance/scalability issues I'm worried about with the async sockets are when you have tens of thousands of sockets connected sending and receiving data fairly often (i.e. in Instant Messaging servers). It is then that you really start to see bottlenecks with Socket IO. JD Conley ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-devel-list] Cross Platform .NET Architecture
I included this question as a side-note in another thread but I think it deserves its own. Is there any documentation on how Mono sets up its class library projects for cross platform .NET development? It seems like there would be some interesting ways you could do this with attributes rather than having IF DEF's everywhere. Is there a particular subsystem I could look at for a good example of how to do this in my own projects? In an ideal world we wouldn't have to write any platform specific code, but this probably isn't going to happen in my project any time soon. Any guidance would be appreciated. JD Conley ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-list] Strange Mono WARNING Output
Currently when running my application I get a lot of WARNING **: : unref on integer called when ref was already 0 warnings. (integer is, I assume, is an interal identifier for a reference variable?) I'm not sure where the warning are coming from. Perhaps the GC? Dereferencing something more than once doesn't seem like that big of a deal. Is there any way to silence the WARNING lines output by the Mono runtime? Thanks JD ___ Mono-list maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/mono-list
[Mono-list] System.Net.NetworkInformation
Are there any plans for, or is there already, an abstraction layer in the Mono classes for determining the local network configuration? I know it's not in the MS Implementation of the .NET Framework, but it is in the Longhorn SDK (http://longhorn.msdn.microsoft.com/lhsdk/ref/system.net.networkinformat ion.aspx). Right now I PInvoke GetNetworkParams and GetAdapterInfo on Windows in the iphlpapi.dll to retrieve the local network information, but I'm not really sure what to use to make it multi-platform. Thanks JD ___ Mono-list maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/mono-list
RE: [Mono-list] vb support
I'm curious about this as well. I think VB support is crucial to getting Mono into many small businesses with VB hackers who want to use .NET and are limited to very small budgets. Not to mention the large enterprises that use VB for all kinds of business applications. It is known to be the most widely used business language, afterall (at least it was a couple years ago). . . Just my $.02. JD -Original Message- From: Christian McHugh [mailto:[EMAIL PROTECTED] Sent: Thursday, October 23, 2003 3:19 PM To: [EMAIL PROTECTED] Subject: [Mono-list] vb support I was wondering what the time line is going to be like for pretty full vb support? Just today trying it out for the first time I think I found some unsupported stuff (filed bug reports) but that means it is not capable of replacing windows for our current needs. Does anyone know how long if ever the vb side will take? ___ Mono-list maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/mono- list ___ Mono-list maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/mono-list
[Mono-list] monobasepath.bat Environment Variable Problem
Title: Message Ina defaultWindows installation of Mono I noticed an issue with the monobasepath.bat file (put in the Windows directory by the install). Itsetsup the environment variables with quotes around them by default. This causes the Mono runtime to search for the machine.config file in a location that does not exist. It also incorrectlysets upthe path for the config directory. Here is what the file looked like when it was installed: set MONO_BASEPATH="C:\Program Files\Mono-0.25"set MONO_PATH="C:\Program Files\Mono-0.25\lib"set MONO_CFG_DIR="C:\Program Files\Mono-0.25\etc\mono" Here is what it should look like in order to function properly: set MONO_BASEPATH=C:\Program Files\Mono-0.25set MONO_PATH=C:\Program Files\Mono-0.25\libset MONO_CFG_DIR=C:\Program Files\Mono-0.25\etc I haven't looked into the code for the installer so I'm not sure what to do to fix it. But hopefully someone can. :) Not being able to find the machine.config was causing issues with the XML DOMwhen trying to load documents from a local file. Thanks, JD
RE: [Mono-list] XMLDocument.Load() With Path Fails on Windows
Then I guess I need some assistance in getting my Mono installation to read the
machine.config. Mono is installed to C:\Program Files\Mono-0.25 (the default).
Whenever I run an executable through the command line, I get the following two
messages:
** Warning **: cannot find C:\Program Files\Mono-0.25\etc\mono\machine.config
Trying to load app config file...
The path Mono is looking in for the machine.config is incorrect. It should be
C:\Program Files\Mono-0.25\etc\mono\machine.config. (the quotes are in the wrong
spot)
Thanks
JD
-Original Message-
From: Gonzalo Paniagua Javier [mailto:[EMAIL PROTECTED]
Sent: Tuesday, July 01, 2003 1:53 AM
To: [EMAIL PROTECTED]
Subject: Re: [Mono-list] XMLDocument.Load() With Path Fails on Windows
El mar, 01-07-2003 a las 08:21, JD Conley escribió:
The following code snippet will fail to load the xml
document located
in the same path as the output binary under Windows.
Attached is the
xml file I was trying to load. This was done on Mono-0.25.
The same
code worked quite well on 0.24.
private void breakXML()
{
System.Xml.XmlDocument x = new System.Xml.XmlDocument();
x.Load(broken.xml);
}
The stack trace is as follows:
System.NotSupportedException: file:///c:/test/broken.xml
in 0x00188 00 System.Net.WebRequest:GetCreator (string)
You need to install a new machine.config (it's in mono/data
directory) to $PREFIX/etc/mono.
Right now you can register schema - handler associations in
machine.config file and the default ones are http/https -
System.Net.HttpRequestCreator and file - FileWebRequestCreator.
-Gonzalo
___
Mono-list maillist - [EMAIL PROTECTED]
http://lists.ximian.com/mailman/listinfo/mono- list
___
Mono-list maillist - [EMAIL PROTECTED]
http://lists.ximian.com/mailman/listinfo/mono-list
[Mono-list] XMLDocument.Load() With Path Fails on Windows
The following code snippet will fail to load the xml document located in
the same path as the output binary under Windows. Attached is the xml
file I was trying to load. This was done on Mono-0.25. The same code
worked quite well on 0.24.
private void breakXML()
{
System.Xml.XmlDocument x = new System.Xml.XmlDocument();
x.Load(broken.xml);
}
The stack trace is as follows:
System.NotSupportedException: file:///c:/test/broken.xml
in 0x00188 00 System.Net.WebRequest:GetCreator (string)
in 0x00050 00 System.Net.WebRequest:Create (System.Uri)
in 0x00060 00 System.Net.WebClient:SetupRequest (string)
in 0x00063 08 System.Net.WebClient:SetupRequest (string)
in 0x00022 00 System.Net.WebClient:OpenRead (string)
in 0x00063 08 System.Net.WebClient:OpenRead (string)
in 0x00071 00 System.Xml.XmlUrlResolver:GetEntity
(System.Uri,string,System.Type)
in 0x00110 00 Mono.Xml.Native.XmlInputStream:.ctor
(string,bool,System.Xml.XmlResolver,string)
in 0x000a5 08 Mono.Xml.Native.XmlInputStream:.ctor
(string,bool,System.Xml.XmlResolver,string)
in 0x00035 00 Mono.Xml.Native.XmlStreamReader:.ctor
(string,bool,System.Xml.XmlResolver,string)
in 0x00018 00 Mono.Xml.Native.XmlStreamReader:.ctor
(string,System.Xml.XmlResolver,string)
in 0x0008a 08 Mono.Xml.Native.XmlStreamReader:.ctor
(string,System.Xml.XmlResolver,string)
in 0x0003a 00 System.Xml.XmlTextReader:.ctor
(string,System.Xml.XmlNameTable)
in 0x0003b 00 System.Xml.XmlTextReader:.ctor (string)
in 0x0002a 00 System.Xml.XmlDocument:Load (string)
in 0x0003f 00 Winfessor.SoapBox.Test.Application.Class1:breakXML ()
in 0x00019 00 Winfessor.SoapBox.Test.Application.Class1:Run ()
---
JD Conley
www.winfessor.com
?xml version=1.0 encoding=utf-8 ?
test/test
