TechTalkz.com Home

Go Back   Windows Help & Support > C# (C Sharp)
Home Register Forum Rules FAQ User Blogs Gallery

Working with named pipes

C# (C Sharp)


Reply
 
LinkBack Thread Tools Display Modes
Old 04-22-2016, 12:30 PM   #1
Anton Shepelev
Guest
 
Posts: n/a
Default Working with named pipes

Hello, all

I have a primitive named-pipe server using synchronious IO.
When my listening thread is frozen at a synchronious call to
ConnectNamedPipe() from kernel32.dll, the thread.Abort()
method seems to have no effect. Is it the expected behavour
and does it mean that one must always use ahynchronous pipe
operations in C#?

--
() ascii ribbon campaign - against html e-mail
/\ http://preview.tinyurl.com/qcy6mjc [archived]

Sponsored Links

  Reply With Quote
Old 04-22-2016, 04:30 PM   #2
Marcel Mueller
Guest
 
Posts: n/a
Default Re: Working with named pipes

On 22.04.16 14.03, Anton Shepelev wrote:
> I have a primitive named-pipe server using synchronious IO.
> When my listening thread is frozen at a synchronious call to
> ConnectNamedPipe() from kernel32.dll, the thread.Abort()
> method seems to have no effect.


Do not use Thread.Abort(). It almost never does what you want.

> Is it the expected behavour
> and does it mean that one must always use ahynchronous pipe
> operations in C#?


AFAIK Thread.Abort injects a ThreadAbortException into the other thread
which is obviously impossible while executing native kernel code.

You should close the pipe handle instead. (Didn't test this in C#.)


Marcel
  Reply With Quote
Old 04-22-2016, 07:30 PM   #3
Anton Shepelev
Guest
 
Posts: n/a
Default Re: Working with named pipes

Marcel Mueller to Anton Shepelev:

> > I have a primitive named-pipe server using synchronious
> > IO. When my listening thread is frozen at a
> > synchronious call to ConnectNamedPipe() from
> > kernel32.dll, the thread.Abort() method seems to have no
> > effect. Is it the expected behavour and does it mean
> > that one must always use ahynchronous pipe operations in
> > C#?

>
> Do not use Thread.Abort(). It almost never does what you
> want.


That's true, but my program is a yet a prototype, and I have
deinitilization in the catch{} clause.

> > Is it the expected behavour and does it mean that one
> > must always use ahynchronous pipe operations in C#?

>
> AFAIK Thread.Abort injects a ThreadAbortException into the
> other thread ->


That's right.

> -> which is obviously impossible while executing native
> kernel code. You should close the pipe handle instead.
> (Didn't test this in C#.)


Hmmm. Do you mean closing the handle from another thread,
i.e. from which I want to initiate the termination of the
listener thread containing the kernel calls?

--
() ascii ribbon campaign - against html e-mail
/\ http://preview.tinyurl.com/qcy6mjc [archived]
  Reply With Quote
Old 04-23-2016, 09:30 AM   #4
Marcel Mueller
Guest
 
Posts: n/a
Default Re: Working with named pipes

Sponsored Links
On 22.04.16 21.20, Anton Shepelev wrote:
> Hmmm. Do you mean closing the handle from another thread,
> i.e. from which I want to initiate the termination of the
> listener thread containing the kernel calls?


Exactly. This is a common way using native APIs. You receive an error
code in this case which is probably transformed to an IOException by the
C# runtime.

From the documentation doing so is not allowed since instance methods
like Close are not thread safe. I am a bit unsure whether this is true.
Maybe only the documentation is not exact enough.
See response from Kim Hamilton (BCL team):
"The "right" way to do an interruptible WaitForConnection is to call
BeginWaitForConnection, handle the new connection in the callback, and
close the pipe stream to stop waiting for connections. If the pipe is
closed, EndWaitForConnection will throw ObjectDisposedException which
the callback thread can catch, clean up any loose ends, and exit cleanly."

The official way with newer Frameworks is
WaitForConnectionAsync(CancellationToken). Seems that they use the
overlapped IO feature of the kernel. Unfortunately the implementation of
CancelIoEx is in the C core.

Sponsored Links

  Reply With Quote
Reply

Thread Tools
Display Modes



< Windows Help - MS Office Help >


New To Site? Need Help?

All times are GMT. The time now is 10:03 PM.


vBulletin, Copyright ©2000 - 2017, Jelsoft Enterprises Ltd.
Copyright © 2005-2008, TechTalkz.com. All Rights Reserved - Privacy Policy
Valid XHTML 1.0 Transitional