emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: OPEN-NETWORK-STREAM connection timeout control?


From: DD
Subject: Re: OPEN-NETWORK-STREAM connection timeout control?
Date: Fri, 12 Jan 2024 23:55:02 -0500
User-agent: mu4e 1.9.18; emacs 27.1


I've got the following, but I'm wondering: is the promise package in
wide use these days?  Promises seem to help with a lot of issues around
the command loop when waiting for the results of asynchronous calls.
I'm wondering if promises will be used more in the future or am I wrong
about them helping to clarify this kind of code?

The other thing I worry about is using process-status to poll for the
end of connection setup rather than a process sentinel.  It says in the
doc that the sentinel can skip states, but I don't think it will skip
"open" here since if it does get to open it will stay there, which means
that open will not be skipped since it's not intermittent, but isa
"last" state??  I don't really care either way, what's better?

To implement this without promises requires more state to be tracked for
the timeout, but the promises package hides that nicely.  I would like
to use promises more in the future -- is that I good idea?  Is there a
better way?


Thanks for your time and attention.

Derek

;; p.el -*- lexical-binding:t -*-

(require 'promise)

(defun do-connect (host port)
  (promise-new (lambda (resolve _reject)
                 (let (sobj)
                   (let ((name (concat "netcatbuf-" host ":" (format "%d" 
port)))
                         (output-buffer nil))
                     (setq sobj (open-network-stream name output-buffer host 
port :nowait t)))
                   (let ((stat (process-status sobj)))
                     (while (and ;; (not (equal stat 'connect))
                             (not (equal stat 'open))
                             (not (equal stat 'failed))
                             (not (equal stat 'closed))
                             (not (equal stat 'exit)))
                       (sleep-for 0.2)
                       (setq stat (process-status sobj)))
                     (cond
                      ((equal stat 'open)
                       (funcall resolve sobj))))))))

(defun do-netcat (host port text)
  (promise-chain
      (promise-wait 7.0 (do-connect host port))
    (then (lambda (res)
            (let ((pobj (cadr res)))
              (message "DLD| do-connection success")
              (process-send-string pobj text)
              ;; NB: TCP half shutdown is needed to trigger service processing.
              (delete-process pobj))))
    (promise-catch (lambda (reason)
                     (netcatbuf-text "janice" 7201 (message "DLD| do-connect 
failed due to %S" reason))))))

(do-netcat "sybil" 7201 "HI THERE HOW ARE YOU?")

;; Ends here.


DD <ddavies@ddavies.net> writes:

> Hello,
>
> I'm using OPEN-NETWORK-STREAM and am unsure about how to control how
> long to wait for the connection to be established or timed out.
>
> I'm fairly sure I would like the call to be synchronous, at least
> until the point of establishing/timing out the connection.  It might
> turn out that, for responsiveness perhaps, I would want to include the
> :nowait keyword, but hopefully I can ignore that for now, because
> after reading the doc and looking at the code I have confusion around
> how that works wrt, at least, how the process object is delivered.
>
> I would like a customizable timeout value so that if a service is down
> emacs stays responsive and times out quickly, since I'm only
> interested in making local area connections in this situation and I
> want to move on quickly to try fallback service(s)..
>
> I hoped there was a timeout keyword for O-N-S, but didn't find it.  I
> looked at lots of other stuff regarding the process object and got
> really side tracked.
>
> I guess I could set an async timer before the O-N-S call and then
> explicitly squelch the O-N-S call if the timer expires before I reset
> it after O-N-S returns?
>
> I'm looking at the elisp code for an example and coming up empty.
> Would be grateful for any help, especially around what is idiomatic in
> this situation, as well as alternative approches.
> q
> Thanks!




reply via email to

[Prev in Thread] Current Thread [Next in Thread]