FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Gentoo > Gentoo User

 
 
LinkBack Thread Tools
 
Old 10-14-2012, 03:07 PM
Michael Mol
 
Default Is my system (really) using nptl

On Sun, Oct 14, 2012 at 5:31 AM, Florian Philipp <lists@binarywings.net> wrote:
> Am 14.10.2012 01:20, schrieb Michael Mol:
>> On Sat, Oct 13, 2012 at 4:18 PM, Canek Peláez Valdés <caneko@gmail.com> wrote:
>>> On Sat, Oct 13, 2012 at 2:50 PM, Michael Mol <mikemol@gmail.com> wrote:
>>> [snip]
>>>> (Well, I'm not certain that POSIX thinks of threads as parents to each other.
>>>
>>> Hence the reason I put "parent" in quotes, and I specified "actually,
>>> the thread that created it".
>>>
>>>> There are *numerous* IPC mechanisms available on Linux. For starters,
>>>> there are sockets (domain, IPv4, IPv6, et al), named pipes, signals,
>>>> mmap()'d files, messaging, etc.
>>>
>>> Yeah, none of them "easy and quickly" to use, or at least not if you
>>> compare it with shared memory.
>>
>> I assume you mean 'shared memory' in the 'many threads to an address
>> space', not the /dev/shm sense.
>>
>
> If we really want to be nit-picking, we have to assume 'shared memory'
> as in malloc'ed [1] or stack memory. Anonymous mmap'ed memory mappings
> are preserved across forks and changes in them can be shared since
> kernel 2.4.

Absolutely.

> [1] Yes, I know that malloc uses mmap but its mappings are MAP_PRIVATE.

For the GNU libc, yeah. I noticed that in strace, and was amused.

--
:wq
 
Old 10-14-2012, 07:19 PM
Florian Philipp
 
Default Is my system (really) using nptl

Am 14.10.2012 17:07, schrieb Michael Mol:
> On Sun, Oct 14, 2012 at 5:31 AM, Florian Philipp <lists@binarywings.net> wrote:
>> Am 14.10.2012 01:20, schrieb Michael Mol:
>>> On Sat, Oct 13, 2012 at 4:18 PM, Canek Peláez Valdés <caneko@gmail.com> wrote:
>>>> On Sat, Oct 13, 2012 at 2:50 PM, Michael Mol <mikemol@gmail.com> wrote:
>>>> [snip]
>>>>> (Well, I'm not certain that POSIX thinks of threads as parents to each other.
>>>>
>>>> Hence the reason I put "parent" in quotes, and I specified "actually,
>>>> the thread that created it".
>>>>
>>>>> There are *numerous* IPC mechanisms available on Linux. For starters,
>>>>> there are sockets (domain, IPv4, IPv6, et al), named pipes, signals,
>>>>> mmap()'d files, messaging, etc.
>>>>
>>>> Yeah, none of them "easy and quickly" to use, or at least not if you
>>>> compare it with shared memory.
>>>
>>> I assume you mean 'shared memory' in the 'many threads to an address
>>> space', not the /dev/shm sense.
>>>
>>
>> If we really want to be nit-picking, we have to assume 'shared memory'
>> as in malloc'ed [1] or stack memory. Anonymous mmap'ed memory mappings
>> are preserved across forks and changes in them can be shared since
>> kernel 2.4.
>
> Absolutely.
>
>> [1] Yes, I know that malloc uses mmap but its mappings are MAP_PRIVATE.
>
> For the GNU libc, yeah. I noticed that in strace, and was amused.
>

Huh? Are there other libcs that do it differently? I can't imagine any
alternative (except of the sbrk function from the bad old days).

Regards,
Florian Philipp
 
Old 10-14-2012, 07:30 PM
Michael Mol
 
Default Is my system (really) using nptl

On Sun, Oct 14, 2012 at 3:19 PM, Florian Philipp <lists@binarywings.net> wrote:
> Am 14.10.2012 17:07, schrieb Michael Mol:
>> On Sun, Oct 14, 2012 at 5:31 AM, Florian Philipp <lists@binarywings.net> wrote:
>>> Am 14.10.2012 01:20, schrieb Michael Mol:
>>>> On Sat, Oct 13, 2012 at 4:18 PM, Canek Peláez Valdés <caneko@gmail.com> wrote:
>>>>> On Sat, Oct 13, 2012 at 2:50 PM, Michael Mol <mikemol@gmail.com> wrote:
>>>>> [snip]
>>>>>> (Well, I'm not certain that POSIX thinks of threads as parents to each other.
>>>>>
>>>>> Hence the reason I put "parent" in quotes, and I specified "actually,
>>>>> the thread that created it".
>>>>>
>>>>>> There are *numerous* IPC mechanisms available on Linux. For starters,
>>>>>> there are sockets (domain, IPv4, IPv6, et al), named pipes, signals,
>>>>>> mmap()'d files, messaging, etc.
>>>>>
>>>>> Yeah, none of them "easy and quickly" to use, or at least not if you
>>>>> compare it with shared memory.
>>>>
>>>> I assume you mean 'shared memory' in the 'many threads to an address
>>>> space', not the /dev/shm sense.
>>>>
>>>
>>> If we really want to be nit-picking, we have to assume 'shared memory'
>>> as in malloc'ed [1] or stack memory. Anonymous mmap'ed memory mappings
>>> are preserved across forks and changes in them can be shared since
>>> kernel 2.4.
>>
>> Absolutely.
>>
>>> [1] Yes, I know that malloc uses mmap but its mappings are MAP_PRIVATE.
>>
>> For the GNU libc, yeah. I noticed that in strace, and was amused.
>>
>
> Huh? Are there other libcs that do it differently? I can't imagine any
> alternative (except of the sbrk function from the bad old days).

These days, and outside of Windows? I'm not familiar with any.

--
:wq
 
Old 10-14-2012, 07:35 PM
James
 
Default Is my system (really) using nptl

Florian Philipp <lists <at> binarywings.net> writes:


> >>> I assume you mean 'shared memory' in the 'many threads to an address
> >>> space', not the /dev/shm sense.

Maybe you guys should agree on tools and the analysis of the results
on the same piece of code?

Maybe a tool such as valgrind/valkyrie would help?

http://valgrind.org/docs/manual/drd-manual.html

Just a thought, on this healthy discussion that is
relevant to the understanding of the many.....

hth,
James
 
Old 10-14-2012, 08:05 PM
"mike@trausch.us"
 
Default Is my system (really) using nptl

On 10/14/2012 03:19 PM, Florian Philipp wrote:
> Huh? Are there other libcs that do it differently? I can't imagine any
> alternative (except of the sbrk function from the bad old days).

Newlib at least uses sbrk, presumably because only requiring that, as
opposed to requiring a fully functional memory mapping interface which
may not exist on whatever it is ported to, is far easier. I suspect
that other smaller and/or embedded-focused libraries that don't assume a
kernel such as Linux or BSD probably also still use sbrk.

--- MIke

--
A man who reasons deliberately, manages it better after studying Logic
than he could before, if he is sincere about it and has common sense.
--- Carveth Read, “Logic”
 
Old 10-14-2012, 10:32 PM
Volker Armin Hemmann
 
Default Is my system (really) using nptl

Am Samstag, 13. Oktober 2012, 19:20:25 schrieb Michael Mol:
> On Sat, Oct 13, 2012 at 4:18 PM, Canek Peláez Valdés <caneko@gmail.com>
wrote:
> > On Sat, Oct 13, 2012 at 2:50 PM, Michael Mol <mikemol@gmail.com> wrote:
> > [snip]
> >
> >> (Well, I'm not certain that POSIX thinks of threads as parents to each
> >> other.>
> > Hence the reason I put "parent" in quotes, and I specified "actually,
> > the thread that created it".
> >
> >> There are *numerous* IPC mechanisms available on Linux. For starters,
> >> there are sockets (domain, IPv4, IPv6, et al), named pipes, signals,
> >> mmap()'d files, messaging, etc.
> >
> > Yeah, none of them "easy and quickly" to use, or at least not if you
> > compare it with shared memory.
>
> I assume you mean 'shared memory' in the 'many threads to an address
> space', not the /dev/shm sense.
>
> >> When one process writes to the chunk of its address space mapped to
> >> that file, the other process can immediately see those changes. All
> >> that remains is sending the other process a signal or some other
> >> driving mechanism to wake it up and have it look at that region for
> >> updates.
> >
> > Yup, certainly neither "easy" nor "quick".
>
> In C (or C++, or any language capable of directly manipulating mmapped
> regions), that's about as dead simple as it gets. Nothing else comes
> close to that degree of efficiency for that degree of simplicity.
>
> >> dbus is only a 'little wonder' in that it provides protocol
> >> constraints and language bindings, which isn't really relevant when
> >> we're talking about same-address-space vs separate-address-space
> >> threading models.
> >
> > You right, of course; it has nothing to do with the discussion at
> > hand. Is just that I *really* like dbus, and I preferred it over
> > almost any other IPC mechanism in Linux.
>
> I know how much you like dbus. I just didn't care for the
> implication that it was the only mechanism of note. There are other
> extraordinarily important mechanisms.
>
> >>> AFAIK, Google Chrome was
> >>> the first desktop program in Linux which uses several processes
> >>> runnning under the same GUI.
> >>
> >> Absolutely not. I used to play a game called 'realtimebattle'
> >
> > OK, I will rephrase it: Google Chrome is the first *relevant* desktop
> > program in Linux which uses several processes runnning under the same
> > GUI.
>
> Chrome was certainly the first *web browser* to take fault
> segmentation through separate processes that far. Before Chrome,
> Firefox used a separate process to thunk between the 32-bit Flash
> plugin and the 64-bit Firefox process on amd64 machines.
>
> Sticking with Desktop systems (so, not touching on SCADA), and
> sticking with Linux (so, not discussing the extensive use of ActiveX
> and OLE on Windows), we're left looking for some other multiprocess
> desktop applications. Here's a quick list of reasonably well-known
> ones:
>
> * VLC, ffmpeg and xine, which all used the xshm extension as a shared
> memory IPC mechanism to push video data rapidly to the X server (a
> separate process)
> * Everything in GNOME that ever used CORBA. I presume there was
> something similar for performing RPC calls within the KDE setup.

yes, dcop. Which made it possible to script every kde app. It was also used
for all those modules to talk to each other. Why they dumbed down to dbus - I
don't know.
--
#163933
 

Thread Tools




All times are GMT. The time now is 09:30 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright ©2007 - 2008, www.linux-archive.org