In Channel§
See primary documentation in context for method close
method close(Channel:)
Close the Channel
, normally. This makes subsequent send
calls die with X::Channel::SendOnClosed
. Subsequent calls of .receive
may still drain any remaining items that were previously sent, but if the queue is empty, will throw an X::Channel::ReceiveOnClosed
exception. Since you can produce a Seq
from a Channel
by contextualizing to array with @()
or by calling the .list
method, these methods will not terminate until the Channel
has been closed. A whenever-block will also terminate properly on a closed Channel
.
my = Channel.new;.close;.send(1);CATCH ;# OUTPUT: «X::Channel::SendOnClosed: Cannot send a message on a closed channel»
Please note that any exception thrown may prevent .close
from being called, this may hang the receiving thread. Use a LEAVE phaser to enforce the .close
call in this case.
In IO::Handle§
See primary documentation in context for routine close
method close(IO::Handle: --> Bool)multi close(IO::Handle )
Closes an open filehandle, returning True
on success. No error is thrown if the filehandle is already closed, although if you close one of the standard filehandles (by default: $*IN
, $*OUT
, or $*ERR
: any handle with native-descriptor 2
or lower), you won't be able to re-open them.
given "foo/bar".IO.open(:w)
It's a common idiom to use LEAVE
phaser for closing the handles, which ensures the handle is closed regardless of how the block is left.
dosub do-stuff-with-the-file (IO )
Note: unlike some other languages, Raku does not use reference counting, and so the filehandles are NOT closed when they go out of scope. While they will get closed when garbage collected, garbage collection isn't guaranteed to get run. This means you must use an explicit close
on handles opened for writing, to avoid data loss, and an explicit close
is recommended on handles opened for reading as well, so that your program does not open too many files at the same time, triggering exceptions on further open
calls.
Note several methods allow for providing :close
argument, to close the handle after the operation invoked by the method completes. As a simpler alternative, the IO::Path
type provides many reading and writing methods that let you work with files without dealing with filehandles directly.
In role IO::Socket§
See primary documentation in context for method close
method close(IO::Socket)
Closes the socket.
Fails if the socket is not connected.
In IO::CatHandle§
See primary documentation in context for method close
method close(IO::CatHandle: --> True)
Closes the currently active source handle, as well as any already-open source handles, and empties the source handle queue. Unlike a regular IO::Handle
, an explicit call to .close
is often not necessary on an IO::CatHandle
, as merely exhausting all the input closes all the handles that need to be closed.
with IO::CatHandle.new:
In IO::Socket::Async§
See primary documentation in context for method close
method close(IO::Socket::Async: )
Close the connected client IO::Socket::Async
which will have been obtained from the listen
Supply
or the connect
Promise
.
In order to close the underlying listening socket created by listen
you can close
the IO::Socket::Async::ListenSocket
. See listen for examples.
In IO::Pipe§
See primary documentation in context for method close
method close(IO::Pipe: --> Proc)
Closes the pipe and returns Proc
object from which the pipe originates.
In Tap§
See primary documentation in context for method close
method close(Tap:)
Closes the tap.