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