The reason why there are no synchronous calls in silverlight is (I
believe) because you can easily deadlock the plugin by attempting a
synchronous call when using the browser http stack. For the web
request to be completed, the browser has to be able to iterate and if
a plugin is blocking,
Hi,
Attached is a patch that adds documentation for all of the
System.Diagnostics.Contracts and System.Diagnostics.Contracts.Internal
namespaces.
Is it ok to commit?
Thanks
Chris
Index: Documentation/en/ns-System.Diagnostics.Contracts.xml
Atsushi,
I doubt I have the required knowledge to implement what you said
right now. As I have said before, I'm still getting familiar with WCF
architeture. I hope I can contribute to your efforts soon.
On Tue, Jul 6, 2010 at 1:08 AM, Atsushi Eno
atsushi...@veritas-vos-liberabit.com wrote:
Alan,
I think I read that explanation before, but responsive UI can be
achieved using background threads, so I don't think silverlight should
force programmers to use the async pattern.
It seems that the async pattern is forced at the socket level, as
shown in
Hi Atsushi,
While examining the file Binding.cs I found the following comment
on the two overloads of CreateContext method :
// FIXME: it seems that binding elements are
// validated so that the last item is a transport.
If you were unsure about where the binding elements should be
Hi,
One possibility is to pad out all x86_prefix instructions to the nearest
32-byte boundary, but that could really bloat things depending on how often
they're used. Do you have any idea of the prefix to non-prefix instruction
ratio? It seems like it'd be pretty low based on looking at
We have pushed a preview release of Mono (actually sort of a release).
Find your files, installers, and repos here:
http://mono.ximian.com/monobuild/preview/download-preview/
Major differences here are in the Mac and Windows GTK+ stacks, which
have been updated to the latest stable releases.
The value is currently ignored, but that is a problem for WebRequest.
For wine bug 23458.
diff --git a/class/System/System.Net/WebClient.cs
b/class/System/System.Net/WebClient.cs
index 8ada916..de62c50 100644
--- a/class/System/System.Net/WebClient.cs
+++ b/class/System/System.Net/WebClient.cs
Hello Thiago,
In what kind of situation does this bring an issue? Is it like, a
binding element after a
TransportBindingElement should not be ignored under certain usage?
For reference, there is a test named
BuildChannelFactoryIgnoresRemaining() in HttpTransportBindingElementTest
in our nunit
