But if that must be done your option is to write a daemon plugin that has (any number of) global variables that processes can use to pass data around.
If you couple that with GET_LOCK() it may work.

But this will require super priv to set the global.

So the Stored Routines lib can dynamically get and set global variables — but that doesn’t help too much because those global variables have some important value, that I should not be tampering with.

The approach that uses process lists will not suffer from any permission-related problems as I assume both sessions would be using the same user, so they will be able to see each other in the process list even without the extra privilege.

It is how the Shard-Query MySQL proxy works, btw. The proxy intercepts the user’s original query, then runs a SQL call like this instead:
select gman_do(‘shard_query_worker’, v_orig_sql);

The gearman worker creates a Shard-Query object and executes the requested query. It then encodes the resultset in JSON in a representation friendly to the proxy so that it doesn’t have to reformulate it.

Since the results come back already properly formatted, the Lua script simply decodes the JSON and sends the array to the client as the result.

This makes the proxy very lightweight and unlikely to crash. Complex scripts are not very stable in my experience but simple ones are.

The VIEW solution brings back some memories from a similar old solution I used. Good call: will look into it!
Though in terms of infrastructure it still requires tables and GRANTs, there’s a lightweight essence to it. Thanks — will check it out.

I’m not too afraid of other people possibly reading the data interchanged between the two sessions.

I need this for my ongoing common_schema project, which is a sort of framework for MySQL. The need for inter-process communication is a shared part for several ideas. One of them would be the control of one “master” script or “dashboard” of some sorts, over scripts running in other connections (so, being able to gracefully stop them etc.).
Another idea involves controlling execution of stored routines (I won’t elaborate too much here, as I’ve only just started looking into this).

So basically, I will have:
One “master/dashboard/manager” connection, looking at “standard/worker” connections (one or more; if need be, I’m willing to settle for one).
The worker connections will send info about their state, and the manager connection will be able to send execution hints like “you should terminate now / you should resume now”.

There will be cooperation between the two; they just need to be able to pass info between themselves.

Like I said, I don’t care too much about eavesdropping at this moment.

If the solution is based on tables — which is the trivial way of sharing data between connections — then I already have all that I need. But this will of course require additional grants, which I prefer to avoid.