Re: smrproxy v2

On 12/11/2024 4:13 AM, jseigh wrote:

On 12/9/24 13:34, jseigh wrote:

On 11/27/24 10:29, jseigh wrote:

 

I'm going to drop working on the whole proxy interface thing.  The
application can decide if it wants to hardcode a dependency on a
particular 3rd party libarary implementation or abstract it out
to a more portable api.
>

>
I figured out where the smr vs smrlite overhead is likely coming from.
>
1) thread_local load about .3 nsecs, 2 for lock/unlock so .6 nsecs.
2) overhead from lazy initialization, about .6 nsecs.
>
smrlite most of the time doesn't show any measurable overhead,
0 nsecs.

 Fixed the whole thread_local issue.  Just don't use it.  I
went back to the api I was using in C and leave it up to
the app to keep track of thread local objects. Fixes the
problem of multiple proxies needing multiple per thread
objects.  This is a language issue, not an api issue.

Well, that works for sure. Humm. If a user wants to register a per-thread object with the polling thread, well... Let them do it! Actually, it's a little more flexible, so to speak... Wrt the api:
void proxy_register(per_thread&)
void proxy_unregister(per_thread&)
lol. ;^)

Theoretically, you could do do lazy initialization with zero
runtime overhead, but for most c++ apps, 1 millisecond is
considered fast, so I don't think there would be much interest
in it.

 And apparantly I am right. :)
 

;^D
Unfortunately, I just seem to not be able to find the time to work on this. Been working on shaders and OpenGL a lot lately.