Hi Leonid, thanks again for your patch. I agree that the global locking in pjsua-lib is really coarse, and you've shown an example where it could be improved (i.e in file player/recorder area).

The intended usage of players is to pre-create them during app initialization, to minimize io bottleneck as you said. And I'd like to remind you that pjsua-lib was never intended to be used as high performance server side app. But still, if you like to force using it as IVR, and if you cannot pre-create the players during startup, the intended usage is to manage the media players/recorders yourself and register the media port with pjsua_conf_add_port()/pjsua_conf_remove_port().

But still, again, if you like to have more fine grained lock granularity in file players/recorders, I would think that it would be much simpler if we just add mutex for it. I'm sure the improvement of lock free mutex will be very very small compared to the whole player creation time (which, if this is considered a problem, pjsua-lib already gives a way to let application manage it itself).

the intended usage is to manage the media players/recorders yourself

Hi Benny! First of all thank you for explanation! I agree this is the best for my use case.

I'm sure the improvement of lock free mutex will be very very small compared to the whole player creation time

You are absolutely right, but I would like to point out: the advantage is not in locking free itself. The advantage is in the ability to create and initialize resources in parallel (in this example, different players/recorders can be created in parallel). This idea is even more useful in conference bridge, where it allows creating, initializing and registering conf ports in parallel.

And thank you again for the offer to change lock granularity. It's not necessary, but I would really appreciate an implementation of the ability to get memory with explicit alignment, something like

void *pj_pool_alligned_alloc( pool, allignment, size)

(like C11 void *aligned_alloc(size_t alignment, size_t size);)

I'm sure the improvement of lock free mutex will be very very small compared to the whole player creation time

You are absolutely right, but I would like to point out: the advantage is not in locking free itself. The advantage is in the ability to create and initialize resources in parallel (in this example, different players/recorders can be created in parallel).

For now we'll leave this in the application (see my prior comment).

And thank you again for the offer to change lock granularity. It's not necessary, but I would really appreciate an implementation of the ability to get memory with explicit alignment, something like

void *pj_pool_alligned_alloc( pool, allignment, size)

Yes! I was thinking exactly the same thing. Feel free to submit a PR.

Closing this for now since #4116 was not accepted.