RFE: use mmap to handle parent-child communication

[sssd-bot]

Cloned from Pagure issue: https://pagure.io/SSSD/sssd/issue/444

• Created at 2010-04-01 20:25:07 by simo
• Closed at 2020-03-24 14:23:19 as wontfix
• Assigned to nobody

---

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.

Comments

---

Comment from sgallagh at 2010-04-06 15:10:03

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

---

Comment from simo at 2010-04-12 14:03:28

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.

---

Comment from sgallagh at 2010-04-12 14:26:32

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.

---

Comment from dpal at 2012-01-19 03:18:27

Fields changed

rhbz: => 0

---

Comment from dpal at 2013-12-02 21:19:54

Fields changed

type: defect => enhancement

---

Comment from simo at 2017-02-24 14:35:20

Metadata Update from @Simo:

• Issue set to the milestone: SSSD Patches welcome

---

Comment from pbrezina at 2020-03-24 14:23:18

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.

---

Comment from pbrezina at 2020-03-24 14:23:19

Metadata Update from @pbrezina:

• Issue close_status updated to: wontfix
• Issue status updated to: Closed (was: Open)