remote_send - client ids - all lost on busy server

:ver

VIM - Vi IMproved 7.4 (2013 Aug 10, compiled Sep 23 2015 09:51:11)

MS-Windows 32-bit GUI version with OLE support

Included patches: 1-873

Thanks for all the help so far, I making it farther using the clientserver features of Vim.

The general flow is this:

1.  A different Vim instance issues a remote_send("VimServerName", 'command", "serverid")

The "serverid" gets populated by Vim and is then used in the remote_peek() or remote_read() functions.

2.  The receiving Vim, must get the clientid of the Vim sending the request, so that it can respond with a client2server() call (if a response is necessary).

Now, the Vim receiving these requests, gets the clientid using:

    let client_id = expand("<client>")

From the docs:

The {clientid} for server2client() can be obtained with expand("<client>")

server2client( {clientid}, {string}) *server2client()*

Send a reply string to {clientid}.  The most recent {clientid}

that sent a string can be retrieved with expand("<client>").

{only available when compiled with the |+clientserver| feature}

Note:

This id has to be stored before the next command can be

received.  I.e. before returning from the received command and

before calling any commands that waits for input.

See also |clientserver|.

Example: >

:echo server2client(expand("<client>"), "HELLO")

Here is my problem, I have Vim clients which send a request to the Vim server.

At the Vim server, the client id is the _same_ for each instance of the client Vims.

They should be different, as each client is unique.

So when we attempt to send back a response with server2client(), only 1 of the Vim clients can receive it.

I have used echomsg to demonstrate.

On the Vim server each time a new request comes in, you use expand("<client>") _immediately_ when getting the call.

The first one, it should be 0x0 as this is the correct Vim instance.

The following 2, should have different client ids as they are coming from 2 different Vim instances.

RemoteDiff_Files: clientid: 0x0 09:57:59 GDIFF

RemoteDiff_Files: clientid: 0x31091c 09:57:59 GDIFF

RemoteDiff_Files: clientid: 0x31091c 09:58:00 GDIFF

From Client 1 I have the following echomsg():

RemoteDiff_Files: serverid: 0x260a2c 09:57:59 GDIFF1

Client 2:

RemoteDiff_Files: serverid: 0x260a2c 09:57:59 GDIFF2

If I put a :sleep 300m before making the remote_send call, then I get unique client ids for each request.

The call I am making is (echomsg slight format change from above):

command! -nargs=* RemoteDiffFiles      :call RemoteDiff_Files(v:servername, <args>)

function! RemoteDiff_Files(...)

    let client_id = expand("<client>")

    let vim_instance = ""

    if a:0 > 0

        let vim_instance = a:1

    endif

    echomsg 'RemoteDiff_Files['.v:servername.'] Vim['.vim_instance.'] clientid['.client_id.'] time['.strftime("%H:%M:%S").']'

endfunction

Just wondering about the threading model of Vim and how this works.

The docs indicate:

The most recent {clientid} that sent a string can be retrieved with expand("<client>").

Problem is when many requests come in at the same time, you only ever get the last client id.  I would have thought since Vim is mostly single threaded, the remote_send() would block until the Vim instance received it.

But it looks like it is multi-threaded on receiving the requests, but then you loose the ability to get the associated client id and can therefore never reliably use server2client() / remote_peek() / remote_send().

I guess an alternate model is to fire an autocmd once per remote_send, and pass in this unique information per request.

David

--
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

---
You received this message because you are subscribed to the Google Groups "vim_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.