[Top][All Lists]

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

bug#10815: counterintuitive results with process-send-string

From: Tiphaine Turpin
Subject: bug#10815: counterintuitive results with process-send-string
Date: Wed, 15 Feb 2012 11:05:49 +0100
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv: Gecko/20111109 Thunderbird/3.1.16


I realized a strange behavior of process-send-string when writing to a socket, and I am wondering whether is is expected or not, and how to live with it.

Here is a very short extract from my code (exact code, no simplification):

  (message "sending command %s" c)
  (process-send-string connection
(concat request-start "\n" c "\n" end-of-message "\n"))
  (message "command sent:   %s" c)

and an extract of the resulting *Messages* (I have replaced the real "command" contents by timestamps):

sending command 1
sending command 2
command sent:   2
sending command 3
command sent:   3
command sent:   1

The other end of the socket connection receives the messages in the order 2, 3, 1, i.e., the same as indicated by "comment sent" debug messages.

It seems that process-send-string,although it is blocking (until sent data is acknowledged), may allow execution of other code (which in this case calls process-send-string again). This seems to be allowed by its specification: "Output from processes can arrive in between bunches.", except that in my setting, I am almost sure than no input can be available at this moment, at least from this connection. In fact, the calls to process-send-string are initiated by after-modify hooks, originating from a single user command (which performs several modifications).

But what is really annoying, is that the inner call to process-send-string takes priority on the pending one: the second message is actually sent before the first, while I would expect the messages to be queued in the right order.

So, I would very much appreciate an opinion on whether this semantics is appropriate. Furthermore, any hint about working around this behavior will be welcome, as I don't know what would be the equivalent of "mutexes" in the absence of threads :-\ .

Finally, it won't be easy to isolate a reproducible test-case (this is about implementing fontification with an external tool), but I can try if this observed behavior seems really impossible from the implementation of process-send-string.


Tiphaine Turpin

reply via email to

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