Process space problem in C#.NET

[MR]

I have two C#.Net projects, both of which create instances of the same C#
class from a separate assembly; the class creates its own thread.

When either project is run alone, it works correctly. However, when they
are run simultaneously, I get a threading error (from
System.Threading.ThreadHelper.ThreadStart_Context) in the project that
starts last.

Don't C# .Net programs run in their own process spaces? Does the fact that
they both instantiate the same class from the same assembly mean that the
process space is shared?

Thanks for any ideas on this.

[Jon Skeet [C# MVP]]

MR <eb*@noemailspam.comwrote:

I have two C#.Net projects, both of which create instances of the same C#
class from a separate assembly; the class creates its own thread.

When either project is run alone, it works correctly. However, when they
are run simultaneously, I get a threading error (from
System.Threading.ThreadHelper.ThreadStart_Context) in the project that
starts last.

Don't C# .Net programs run in their own process spaces? Does the fact that
they both instantiate the same class from the same assembly mean that the
process space is shared?

Thanks for any ideas on this.

Yes, they'll be in their own process spaces - but what's the error
you're getting?

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
World class .NET training in the UK: http://iterativetraining.co.uk

[MR]

The final error is:

System.IO.EndOfStreamException was unhandled
Message="Unable to read beyond the end of the stream."

The stack trace is:

Source="mscorlib"
StackTrace:
at System.IO.__Error.EndOfFile()
at [locations in my program]
at System.Threading.ThreadHelper.ThreadStart_Context( Object state)
at System.Threading.ExecutionContext.Run(ExecutionCon text
executionContext, ContextCallback callback, Object state)
at System.Threading.ThreadHelper.ThreadStart()

Both processes create a thread to read from the same socket (the socket is
from the same source, a third-party control). The socket is created using
the TpClient class in System.Net.Sockets.

The error may be due to the fact that they both read from the same source,
and the thread in the first instance has read all the data before the thread
in the second instance can read it. But I've used multiple instances of an
ActiveX control to do the same thing from the same control, without any
errors.

If you need any more information, please let me know, and thanks for any
help you can give me.
"Jon Skeet [C# MVP]" <sk***@pobox.comwrote in message
news:MP*********************@msnews.microsoft.com. ..

MR <eb*@noemailspam.comwrote:

>I have two C#.Net projects, both of which create instances of the same C#
class from a separate assembly; the class creates its own thread.

When either project is run alone, it works correctly. However, when they
are run simultaneously, I get a threading error (from
System.Threading.ThreadHelper.ThreadStart_Context ) in the project that
starts last.

Don't C# .Net programs run in their own process spaces? Does the fact
that
they both instantiate the same class from the same assembly mean that the
process space is shared?

Thanks for any ideas on this.

Yes, they'll be in their own process spaces - but what's the error
you're getting?

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
World class .NET training in the UK: http://iterativetraining.co.uk

[Jon Skeet [C# MVP]]

MR <eb*@noemailspam.comwrote:

<snip>

Both processes create a thread to read from the same socket (the socket is
from the same source, a third-party control). The socket is created using
the TpClient class in System.Net.Sockets.

Right, I can see how that would be a problem. Sockets aren't meant to
be read from multiple processes.

The error may be due to the fact that they both read from the same source,
and the thread in the first instance has read all the data before the thread
in the second instance can read it. But I've used multiple instances of an
ActiveX control to do the same thing from the same control, without any
errors.

If you need any more information, please let me know, and thanks for any
help you can give me.

It sounds like you really need to remove the idea of reading data from
the same socket from different processes. I just can't see that
working.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
World class .NET training in the UK: http://iterativetraining.co.uk

[MR]

Thanks very much for your reply. The had separated the ActiveX control into
two processes because I had what appeared to be thread contention, and that
solved the problem. Since I didn't write the ActiveX control (it was
supplied by a third party), I had no other way handle the problem.

However, the socket runs on its own thread. In this case, I will just
combine the functions into the same process, as
you suggest.

Thanks again.
"Jon Skeet [C# MVP]" <sk***@pobox.comwrote in message
news:MP*********************@msnews.microsoft.com. ..

MR <eb*@noemailspam.comwrote:

<snip>

>Both processes create a thread to read from the same socket (the socket
is
from the same source, a third-party control). The socket is created
using
the TpClient class in System.Net.Sockets.

Right, I can see how that would be a problem. Sockets aren't meant to
be read from multiple processes.

>The error may be due to the fact that they both read from the same
source,
and the thread in the first instance has read all the data before the
thread
in the second instance can read it. But I've used multiple instances of
an
ActiveX control to do the same thing from the same control, without any
errors.

If you need any more information, please let me know, and thanks for any
help you can give me.

It sounds like you really need to remove the idea of reading data from
the same socket from different processes. I just can't see that
working.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
World class .NET training in the UK: http://iterativetraining.co.uk