Это плохая идея, чтобы передать канал содержит дескриптор файла в goroutine? - PullRequest
0 голосов
/ 08 ноября 2019

ORIGINAL 09/11/2019

conn := createConnection() // or a file handle

go getData(conn)

Возможно ли, что нить для getData, находится в другой нити ручки conn. Следовательно, это может привести к ошибке соединения.

---- ОБНОВЛЕНО 11/11/2019 09:00 ----

Senario 1

func createConnection() handler {
  ... create a socket connection (tcp://.....) or file open handler
  return conn
}

func sendData(conn handler, data string) {
  conn.send(data)
}

conn := createConnection() // or a file handle

go sendData(conn, "test data")

Senario 2

func createConnection() handler {
  ... create a socket connection (tcp://.....) or open file handler
  return conn
}

func sendData(ch chan handler, data string) {
  conn := <- ch
  conn.send(data)
}

ch := make(chan conn, 10)

ch <- createConnection() // or a file handle

go sendData(ch, "test data")

История создания:

Я работал над задачей прокси-передачи данных на сокет-сервер. Моим решением проблемы было использование идеи [Senario 2].

Мало кто из моих коллег - программист на C, работающий с программированием на системном уровне. Они отметили, что golang channel лучше содержит только данные - помещение обработчика файла в канал может вызвать неизвестную проблему, такую ​​как: поток для channel get находится в другом потоке channel put, поэтому обработчик файла также может отсутствовать.

Насколько я понимаю, Голанг должен решить проблему сам по себе. Я тогда задал вопрос выше.

Рассматривая некоторые исходные коды проектов, связанных с сокетами, я думаю, что [Senario 1] в порядке. Тем не менее, [Senario 2] все еще остается вопросом для меня.

Опять же, мой вопрос не [могу ли я передать дескриптор файла в функцию], все знают: «Это да». Вопрос в golang CSP, используйте go и chan вместе, с обработчиком файлов, может ли это быть проблемой? Или, что более важно: использование указателя в golang channel put и channel get может быть проблемой или нет;это большое "нет нет" в Си по книгам. Если в Голанге все хорошо, как Голанг достигает этого?

---- ОБНОВЛЕНО 11/11/2019 10:00 ----

Вопрос касается только Голанга. Такой проблемы не бывает с node.js, так как это однопоточный язык. Вопрос касается потоков и обработчика файлов. К тому же, у меня ограниченные знания об этой проблеме, я прошу прощения, чтобы задать плохой вопрос или предоставить информацию о пропущенных ведущих.

---- ОБНОВЛЕНО 11/11/2019 10:40 am ----

Я вновь подтвердил со своим коллегой, что проблема заключается в том, что «каждый раз, когда код запрашивает обработчик файла, система возвращает число. Однако число уникально только в одном процессе, что означает один и тот же номер обработчика файла, в другом процессе». , может указывать на другой ресурс. Я не уверен, что горутин позаботится об этом или нет ".

1 Ответ

1 голос
/ 08 ноября 2019

Нет ничего плохого в том, чтобы передать дескриптор соединения в отдельную программу, если вы внимательно относитесь к следующему:

  • Не закрывайте ручку во время работы программы или пишите программучтобы справиться с этим.
  • Если вы используете дескриптор из нескольких групп, убедитесь, что соединение, с которым вы имеете дело, является поточно-ориентированным, или установите вокруг него замок.
  • Будьте ясныи явно о том, кто собирается закрыть его. Goroutine может закрыть его, когда это будет сделано, или другой goroutine закроет его, когда вся работа с использованием ручки завершена.
Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...