-
Notifications
You must be signed in to change notification settings - Fork 4.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
proposal: delete unix socket path on Dispose of bound Socket #45537
Comments
Tagging subscribers to this area: @dotnet/ncl Issue Detailsaspnetcore repo has an open issue about unix socket not getting cleaned up on exit: dotnet/aspnetcore#14134. The socket path of a unix domain socket acts as the address. With the current behavior, this program fails: using System;
using System.Net.Sockets;
namespace console
{
class Program
{
static void Main(string[] args)
{
var endpoint = new UnixDomainSocketEndPoint("/tmp/mysocket");
var socket = new Socket(AddressFamily.Unix, SocketType.Stream, ProtocolType.Unspecified);
socket.Bind(endpoint);
socket.Dispose();
socket = new Socket(AddressFamily.Unix, SocketType.Stream, ProtocolType.Unspecified);
socket.Bind(endpoint);
}
}
}
Deleting the file is a visible change, so we should consider backwards compatibility. Users are likely to have @wfurt @antonfirsov @stephentoub @dotnet/ncl what do you think?
|
Sounds reasonable to me -- @antonfirsov @geoffkizer any thoughts? |
Sounds reasonable to me. |
Triage: If there are no compat issue (with code manually deleting the file today), we are fine with this. |
aspnetcore repo has an open issue about unix socket not getting cleaned up on exit: dotnet/aspnetcore#14134.
The socket path of a unix domain socket acts as the address.
When the
Socket
gets disposed, we should make the address available by deleting the file.With the current behavior, this program fails:
Deleting the file is a visible change, so we should consider backwards compatibility.
Users are likely to have
File.Delete
already in their applications. Those calls will no-op (onENOENT
).@wfurt @antonfirsov @stephentoub @dotnet/ncl what do you think?
The text was updated successfully, but these errors were encountered: