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

[Tiphaine Turpin]

Hello,

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.

Regards,

Tiphaine Turpin