#444 RFE: use mmap to handle parent-child communication
Closed: wontfix 3 years ago by pbrezina. Opened 13 years ago by simo.

In the krb provider and the ldap provider we use some child processes to deal with blocking operations.
These processes tend to be tightly coupled to the calling parent, it may make sense to use mmap memory as a communication channel between child and parent instead of usin a pipe. This would remove the need to deal with marshalling/unmarshalling routines and handling read()/writes(). It should simplify the code quite a bit in that area.
The only pre-requisite is that the size of the shared memory needed to exchange information is known in advance.


This is a case of optimizing unnecessarily. The code in question is invoked very rarely, so using mmap() would provide no measurable performance improvement.

milestone: NEEDS_TRIAGE => SSSD Deferred
priority: minor => trivial

FWIW: It is not just a speed optimization issue, it is mostly simplification, we had lot of issues in making the code ARM safe, ?But if we use fixed structures within the mmap region, the compiler will fix alignment issues for us. It will also reamove the need for all the extra code required to catch errors with pipes operations (read/write).

Anyway I am ok with deferring, just wanted to make sure this is not mischaracterized.

The problem is the fixed structure. You can see from ticket #432 that we need to ensure that we can handle arbitrary-length replies from the child. I suppose we could manage some tricks with buffered sending, but I definitely think this is overcomplicated for the immediate future.

Fields changed

rhbz: => 0

Fields changed

type: defect => enhancement

Metadata Update from @simo:
- Issue set to the milestone: SSSD Patches welcome

7 years ago

Thank you for taking time to submit this request for SSSD. Unfortunately this issue was not given priority and the team lacks the capacity to work on it at this time.

Given that we are unable to fulfill this request I am closing the issue as wontfix.

If the issue still persist on recent SSSD you can request re-consideration of this decision by reopening this issue. Please provide additional technical details about its importance to you.

Thank you for understanding.

Metadata Update from @pbrezina:
- Issue close_status updated to: wontfix
- Issue status updated to: Closed (was: Open)

3 years ago

SSSD is moving from Pagure to Github. This means that new issues and pull requests
will be accepted only in SSSD's github repository.

This issue has been cloned to Github and is available here:
- https://github.com/SSSD/sssd/issues/1486

If you want to receive further updates on the issue, please navigate to the github issue
and click on subscribe button.

Thank you for understanding. We apologize for all inconvenience.

Login to comment on this ticket.

Metadata