In my specific case, I'm creating a plugin that's part of a multi-script bundle of code to manage corporate network VPN connections. The BitBar plugin's purpose is to show the current up/down state of the VPN, provide statistics about the connection in grey items in the menu (connection duration, how long until you get automatically cut off, etc), and Connect/Disconnect options.

The "First time ever" scenario would be useful because I could use that to automatically install all the scripts, binaries, packages, and LaunchAgent plist files needed to support things. That would let the BitBar plugin basically handle it all, instead of needing a custom installer like I have now that installs the BitBar plugin, creates the directory the binaries go into, downloads needed packages, etc.

Having a "First time for this version of the plugin" event/notification/signal would let me check to see if the tools are up to date, but only if necessary, saving some time during startup. It would also let me do things like update the format of configuration data as needed, and that kind of thing, if necessary (there's no need for it as things stand but I could see it in the future).

Both of those would also let me do things like handle any needed LaunchAgent setup that needs doing.

Having a "First time since BitBar started up" would let me do things like launch needed background tasks, and that kind of thing. I don't have to launch them on subsequent runs of my script, since those tasks are already running after the first pass.

Yeah, there are ways around some these, either by simulating these events using things like a marker file that I can create/delete to indicate first-run scenarios, but that can be pretty fragile. Having a proper mechanism to make my script aware of which scenario is the case would be very useful.

I can think of many other ways they would be handy, but you asked for my specific case. :)

<!--- ⬆️ Add your issue title in the "Title" field above ⬆️ -->

🤷🏽‍♂️ Current Behaviour

<!--- Bug Reports: Describe what currently happens. Feature Suggestions: Describe how a feature currently works (if it exists). --> I usually notice a high CPU usage:

🎯 Expected Behaviour

<!--- Bug Reports: Describe what should have happened. Feature Suggestions: Describe how a feature should work. --> Normal CPU usage

👟 Steps to Reproduce (S2R)

<!--- (Bug Reports only) Provide a simple set of steps for reproducing the issue. --> I suspect it has started when I rebooted and started getting this kind of notification:

🏡 Environmental Context

<!--- (Bug Reports only) Provide details about where the issue occurred. --> App Version 11.0.2 Installation Type Setup Operating System MacOS Catalina 10.15.7

@Kratacoa I'm using a custom function for this purpose for a quite a long time: search-file. It is basically an emulation of Vim's behavior of gf, which is capable of smart recursive search under several paths. Paired with another function - smart-select-file and mapped to gf like this I have never used inbuilt gf feature of Kakoune. See if this works for you?

The above isn't the only error which can occur on the run, some of which seem pretty odd so I suspect some form of corrupt state.

Sometimes the line 5562 in Remotery.c:

rmtU32 nb_thread_profilers = LoadAcquire(&thread_profilers->nbThreadProfilers);

returns 1, and so triggering assert(table_size_log2 >= 2); in GaloisLFSRMask.

The assert on line 4665 assert(sample != NULL); in FlattenSamples also triggers on some runs.

There are lots of other weird errors which occur. I've tried running with _NO_DEBUG_HEAP off (i.e. not set to 1 so full debug heap), but this doesn't help narrow things down.

I have to do other work now, and I don't sufficiently understand the code to know where to add extra debugging to narrow things down. If you have any suggestions of what to look at I can have a go debugging tomorrow.

In case this is my own code causing a problem, I'd be happy to run your test code which runs lots of threads doing work. I have confirmed that removing the remotery calls results in a working example.

Same as #2646 @nlohmann This should be a simple fix.

See this link on how to sync an upstream repo: https://docs.github.com/en/github/collaborating-with-issues-and-pull-requests/syncing-a-fork

Syncing repos

Syncing repos

Normally graphics API supports glFlush command analog that allows to wait for all GPU commands to be executed. So you can do something straightforward like:

TEST_CASE("TestRenderer")
{
     MyRenderer r;
     while( !r.done() )
     {
          r.drawFrame();
          r.flush();
          CHECK(/*something*/);
     }
}

Anyway, passing runtime data and executing specific tests in a specific order with some user code between, sounds like the wrong way to do things. Maybe it's better to write your own testing loop and use doctest just as an assertion library.

If I add a return at Remotery.c#L5221 so the GatherThreads no longer makes does anything, then I get an assert at: Remotery.c#L5973 after a while - but much later than the initial issue showed in the call to Thread32Next.

Surrounding data:

I did not have a web browser connected at the time.

@mawww, should be fine now

Duly noted. I have instead casted the length parameter when used in the snprintf calls.

(call back to the client after it connects)

That's interesting, but meh. IMO too complicated, I'd rather create the throw-away stream: the operation is not so common anyway, so the additional wasted connection doesn't make a difference; also the version mismatch is actually an exceptional situation.

or make version check as part of data that goes through the stream

This could be done by having something like

rpc::sink<std::variant<version, large_struct_fragment>>

Then sending first the version, then large struct fragments. But that's ugly :( We know during compile time that version comes only once, then everything else is fragments. But because of the APIs we need to dispatch on the variant on each received element.

Anyway you cannot make returning sink optional anyway.

:(

On Mon, Mar 01, 2021 at 07:37:50AM -0800, Kamil Braun wrote:

The only way I see to resolve this is to have the client contact the server twice:

1. once to obtain need_stream,
2. the second time to obtain the source (if need_stream == true).

Unfortunately, there's a problem here: between 1 and 2 need_stream may change.

Good point. You can make server create the stream instead (call back to the client after it connects), or make version check as part of data that goes through the stream. Anyway you cannot make returning sink optional anyway. It has to be closed explicitly by the stream initiator.

-- Gleb.

This is going to take me a couple days to sort out properly. MS has gone all-in on rearranging headers so that the same set of includes doesn't work with different SDK versions. Right now 2015 can't find <timeapi.h>

Let me know if you have anything you want me to try out on my end, thanks!

I already explained the logic: the client doesn't know need_stream. Only the server does. So the server knows whether or not to open a stream. So we have a contradiction:

1. the client must decide whether to open a stream before contacting the server,
2. but the client can know how to open a stream only after contacting the server.

The only way I see to resolve this is to have the client contact the server twice:

1. once to obtain need_stream,
2. the second time to obtain the source (if need_stream == true).

Unfortunately, there's a problem here: between 1 and 2 need_stream may change.

I'll try and dig more into it when I get time later on since you can't replicate.

On Mon, Mar 01, 2021 at 06:18:00AM -0800, Kamil Braun wrote:

How does the client (the one executing the snippet you provided) know the value of need_stream? In whatever way you want it to. You know the logic, I have no idea. The point is it is done before you open a stream, not after.

-- Gleb.

Wow...

I'd actually already tried that, forgot to mention - the issue still occurs.

Any result commenting out ThreadProfilers_GetThreadProfiler?

I can't reasonbly suspect the outer loop. Something in the inner loop is trampling the stack, maybe.

That reads 38.

More:

Somewhat amazed this pastes so easily from VS...

Actually, what does thread_profilers->nbThreadProfilers say?

No repro here, I'm afraid.

What happens if you comment out the ThreadProfilers_GetThreadProfiler logic?

Could you include a snippet with the full (high-level) algorithm of the client? Including how he obtains need_stream.

How does the client (the one executing the snippet you provided) know the value of need_stream? In my previous snippet, it was the server who can calculate need_stream.

On Mon, Mar 01, 2021 at 06:11:46AM -0800, Kamil Braun wrote:

Could you provide a snippet of code that sketches the solution? In particular, I'm interested in the type(s) of the handler(s).

Do not create an rpc stream until you verified that you will use it. What king of sketch do you need for that?

if (need_stream) { sink = create one source = rpc_send(sink); }

?

-- Gleb.