Переименование потока

Имена потоков в .NET (и Java) используются исключительно для целей отладки и диагностики. Хотя логика, что, поскольку Java может переименовывать свои потоки, .NET может делать то же самое, ошибочна (поскольку файл.NET-поток - это оболочка над системным потоком с дополнительной функциональностью, как и поток Java, но в остальном они не связаны), нет никакого вреда как такового в изменении имени потока, кроме риска поломки в будущем версий, так как вы используете непубличный API.

Однако по какой причине вы его меняете? Я думаю, что он был сделан только для чтения, чтобы избежать создания потоков "кухонной раковины", которые выполняют всевозможные задачи. Конечно, есть исключения, но я бы посоветовал вам подумать о том, является ли дизайн, который требует этого, правильным.

У потоков на уровне ОС нет имен. На самом деле, это просто удобство.

Существует определенная вероятность того, что что-то полагается на неизменность имени, что и требует дизайн. Нарушая эту инкапсуляцию, вы рискуете сломать то, что (добросовестно) на нее полагается. Я не могу привести конкретный пример, но поскольку это свойство можно использовать любым мыслимым образом, проблема безгранична. В качестве теоретического примера что-то может использовать имя потока в качестве ключа в коллекции.

Я хотел бы знать, есть ли офигительный конкретный пример, поскольку я тоже использую log4net и смотрю, к чему вы клоните. :)

Обновление

Это определенно вызвало у меня интерес как пользователя log4net. Не желая поддерживать вилку log4net, это более безопасное возможное решение.

1. Напишите оболочку для log4net, т.е. интерфейс типа ILog (у меня уже есть одна и 15 минут работы).

2. Используйте технику локальной переменной потока для записи имени потока (например, с помощью метода расширения Thread.LoggingName = "бла-бла-бла") в точках входа в ваши компоненты.

3. В оболочке журналирования временно измените имя потока, а затем снова измените его после входа в систему.

Это заботится о переименовании потоков и переименовании их снова, так что если что-то, что не называет потоки, выходит из системы, оно не выходит из системы с неправильным именем.

Обновление 2

Примерный пример техники:

public class MyComponent
{
    public void EntryPoint()
    {
        MyLogger.CurrentLoggerThreadName = "A thread contextual name.";

        _myLogger.Info("a logging message.");

        SomeOtherMethod();
    }

    private void SomeOtherMethod()
    {
        _myLogger.Info("another logging message with the same thread name.");
    }
}

public class MyLogger
{
    [ThreadStatic]
    private static string _CurrentLoggerThreadName;

    private static readonly FieldInfo NameField = typeof(Thread).GetType().GetField("m_Name", BindingFlags.Instance | BindingFlags.NonPublic);

    public static string CurrentLoggerThreadName
    {
        get { return _CurrentLoggerThreadName; }
        set { _CurrentLoggerThreadName = value; }
    }

    private static void LogWithThreadRename(Action loggerAction)
    {
        Thread t1 = Thread.CurrentThread;

        string originalName = (string)NameField.GetValue(t1);

        try
        {
            NameField.SetValue(t1, CurrentLoggerThreadName);
            loggerAction();
        }
        finally
        {
            NameField.SetValue(t1, originalName);
        }
    }

    public void Info(object message)
    {
        LogWithThreadRename(() => _iLog.Info(message));
    }

    //More logging methods...
}

Изменение имени, или попытка изменить имя, вполне может что-то сломать. Если реализация System.Threading.Thread изменится таким образом, что поле m_Name будет называться m_ThreadName, например, в будущей версии .NET Framework, или даже в пакете обновлений или исправлении (хотя это и маловероятно), ваш код выдаст исключение.

Я бы не стал менять название потока таким образом, как это делаете вы. Хотя вы делаете то же самое, что потребовала бы операция write-many, вы не знаете, что не существует поведения, зависящего от того, что операция write-once.

Например, отладчик, получив имя потока, может кэшировать это имя и больше не вызывать объект для его получения.

Здесь также возникает вопрос дизайна, почему вы зависите от имени потока, чтобы помочь с протоколированием; вы полагаетесь на поведение регистратора, чтобы указать часть операции, которую вы пытаетесь протоколировать.

Если вы хотите зафиксировать определенную семантику, вам не следует формировать регистратор и поток в соответствии с шаблоном, который позволит зафиксировать эту семантику. Вместо этого явно укажите семантику регистратору в конкретный момент времени.