rulinux.net - Форум - Development - CL, usocket и timeout

Re:CL, usocket и timeout

Tue, 15 Mar 2016 18:36:04 +0300

>(setf (sockets:socket-option socket :receive-timeout) n)
receive-timeout это SO_RCVTIMEO, судя по коду.

В usocket этот таймаут можно задать при создании сокета, что я и делал в первом посте, но, судя по всему, он не срабатывал на чтение, видимо только на установку соединения работает. Или в usocket там что-то придумали странное с ним, даже не знаю.

Re:CL, usocket и timeout

Tue, 15 Mar 2016 16:28:15 +0300

С помощью iolib это делается ещё проще:

(setf (sockets:socket-option socket :receive-timeout) n)

Только будет ли read-line и другие методы для потоков корректно обрабатывать эти таймауты или это только для низкоуровщины? По-моему read-line пофиг на таймауты.

Я usocket не трогаю, т.к. он скорее мертв, чем жив.

Re:CL, usocket и timeout

Sun, 13 Mar 2016 00:17:41 +0300

Спасибо.

>А лучше напиши автору, как сделать read-line с таймаутом. Может подскажет
Я решил не тревожить автора из-за такой мелочи. Посмотрел на iolib - в моём случае то же самое, что и usocket, только ещё дополнительно библиотеку какую-то компилировать, решил не трогать то, что работает.

В общем, попробовал всякие разные способы, попытался именно read-line использовать - всё как-то криво, то eof не поймаешь, то ещё чего. Плюнул, задумался, посмотрел, как люди делают, и утащил решение из hunchentoot, которое только для сокетов подойдёт, а не для произвольного стрима:

lisp

(defun set-read-timeout (socket stream timeout)

  "Set timeout for read operations on stream. Taken from hunchentoot code."

  (declare (ignorable socket stream))

  #+:ecl

  (setf (sb-bsd-sockets:sockopt-receive-timeout socket) timeout)

  #+:openmcl

  (setf (ccl:stream-input-timeout socket) timeout)

  #+:cmu

  (setf (lisp::fd-stream-timeout stream) (coerce timeout 'integer))

  #+:sbcl

  (setf (sb-impl::fd-stream-timeout stream) (coerce timeout 'single-float))

  #+:abcl

  (java:jcall (java:jmethod "java.net.Socket" "setSoTimeout"  "int")

              socket

              (* 1000 timeout)))

Наверное сразу надо было в эту сторону смотреть. Впрочем, потом оказалось, что у меня с ABCL и ECL проект не работает даже, ну да и ладно.

Re:CL, usocket и timeout

Fri, 11 Mar 2016 17:52:17 +0300

А вот хуй я сам знаю!

Первое, что приходит на ум, воспользоваться стандартной функцией read-char-no-hang и делить на строки вручную. И так же вручную сделать таймаут. Но это тупо как-то.

lisp

(defpackage test

  (:use #:cl)

  (:export #:run))

(in-package :test)

(defun process (socket)

  (unwind-protect

       (format t "Received ~A~%"

               (coerce

                (loop for char = (read-char-no-hang socket)

                   while char collect char) 'string))

    (close socket)))

(defun run (port)

  (bordeaux-threads:make-thread

   (lambda ()

     (let ((socket (sockets:make-socket :address-family :internet

                                        :type :stream

                                        :connect :passive

                                        :local-host #(127 0 0 1)

                                        :local-port port)))

       (loop while t do

            (let ((connection

                   (sockets:accept-connection socket)))

              (process connection)))

       (close socket)))))

А лучше напиши автору, как сделать read-line с таймаутом. Может подскажет

https://github.com/sionescu/iolib

У себя я делал с помощью receive-from в массив октетов, с последующим преобразованием в строку и с I/O multiplexer'ом, где можно и таймаут обработать.

Re:CL, usocket и timeout

Fri, 11 Mar 2016 16:15:33 +0300

Щас постараюсь ответить, как я делал. usocket говно, кстати, лучше iolib

Re:CL, usocket и timeout

Fri, 11 Mar 2016 13:12:11 +0300

когда соединение хитрым образом рвётся - надо использовать TCP Keepalive

Re:CL, usocket и timeout

Fri, 11 Mar 2016 12:08:32 +0300

Хочется обойтись read-line ради простоты кода, конечно.

Так там сходу есть read-char-no-hang, который, впрочем, потребует того же sleep. Конкретно в стандарте CL я не нашёл чтения с таймаутом (стандарт-то от 94-го года, а составлялся, по сути, лет на 10 раньше).

В конкретных реализациях (тот же SBCL) есть и таймауты, и всё, что нужно, но мой извращённый ум почему-то решил, что стоит поискать что-то универсальное, хоть в чудесном мире общелиспа привязка к реализации является вполне нормальным и адекватным решением по множеству причин.

Re:CL, usocket и timeout

Fri, 11 Mar 2016 11:49:10 +0300

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

CL, usocket и timeout

Fri, 11 Mar 2016 10:54:32 +0300

Надо же разбавить сие болото.

Вот, допустим, у меня есть такой код (упрощённый):

lisp

(let* ((socket (usocket:socket-connect server port :timeout timeout))

       (stream (make-stream socket encoding)))

  (do ((line

        (read-line stream nil)

        (read-line stream nil)))

      ((not line))

    (do-something-with-line)))

Всё отлично, но возникают редкие ситуации, когда соединение хитрым образом рвётся, а цикл остаётся висеть на read-line до окончания времён.

Как я понимаю, timeout срабатывает только на установление соединения, а сам read-line спокойно может заблокировать текущий поток на неопределённое время (ну или я совсем что-то не то делаю). Предполагаю, что нужен какой-то таймаут на чтение, после которого можно будет всё это дело прервать и переконнектиться. Вопрос, собственно, в том, как его кроссплатформенно (SBCL, CCL, ECL, чем больше - тем лучше) реализовать наиболее красивым способом.

Сходу находится какой-то trivial-timeout, но он страшный, мёртвый и, по заверением разработчиков, может не работать. Второй вариант - решение из comp.lang.lisp с бесконечным циклом и sleep. Вроде бы должно сработать, но бесконечные циклы со sleep меня пугают (хотя можно, если прижмёт).Третье - поиграть с usocket:wait-for-input, но все его применяют для серверных вещей, а у меня типа клиентское.

Также в качестве извращённого варианта можно предложить какой-нибудь watchdog thread (у меня и так многопоточная штука), который будет проверять время последнего сработавшего read-line и рестартить треды по необходимости. Но это немного странно выглядит, да и надо хэш-таблицу с локами делать.

Может кто подскажет самое изящное и простое решение?