Article View: comp.sys.powerpc
Article #2549Re: Message passing speed on BeBox
From: Bill Moyer
Date: Tue, 21 Nov 1995 16:05
Date: Tue, 21 Nov 1995 16:05
45 lines
2842 bytes
2842 bytes
In article <james-2011950941130001@slip-21-7.ots.utexas.edu>,
James McCartney <james@astro.as.utexas.edu> wrote:
>In article <umisef.51.30B0765F@halls1.cc.monash.edu.au>,
>umisef@halls1.cc.monash.edu.au (Bernd MEYER - Bernie) wrote:
>
>> I might try sending a sructure through that pipe, instead of having
>> the printf and scanf functions there. It should speed things up
>> tremendously.
>
>Be messages are not just structures, they are associative dictionaries
>which you can query for information of a certain type. If you just
>send a C struct through a pipe you have to know what it is you are
>receiving. A BMessage can be asked what it contains. Data is tagged
>by keyword and type.
Hmm .. Are there details of the message implementation in the
BeBook on //www.be.com? It seems at first glace like you could do
this by preceeding each structure with a structure which describes
that structure in a manner standardized across all applications.
An interesting alternative method for IPC might be to allow
applications to create a structure in shared memory of the format:
[control] [fields definition] [record1] [record2]..[recordn]
Where [control] contained access semaphores, the number of
records in the structure, and pointers to the first and last
valid records (ie, making a circular queue), [fields definition]
contained a globally-understood structure defining the format
of the records, and records1..n were space for structures of the
type defined in [fields definition].
An entry for this shared memory structure could be placed in
a globally accessible table so that processes can sync, and once
a "connection" is made writing data to the queue would be as fast
as copying blocks between memory location (with a little overhead
for semaphore management). It wouldn't be dynamic like the BeOS
messages, so it's not a replacement, but it would be a fast, cute
way of implementing record-based (as opposed to byte-based, like
in a pipe) IPC.
/---\ /---\ /= / ttk@rahul.net CCS ZuulOS Development Labs
= = = / GCS d-- H s++: g+(?) p0+(4++) au a! w++ v-?
= = = \ C++++ UBLS++ P+ L+ 3- E+ N++ K !W--- M-- V--
= = = \ -po+ Y+ t+ 5++ !j R G'' !tv b+ D++(+++) B---
e+ u+ h+*>++ f n+(++) y++*
Technical Details
Message-ID:
<48stbk$pmv@hustle.rahul.net>Path:
arc1-ca.pugleaf.net!ttk.a2i!ttkReferences:
<jazzDI1u41.16H@netcom.com> <ACD5092596684DB87@jake-6f.ip.realtime.net> <umisef.51.30B0765F@halls1.cc.monash.edu.au> <james-2011950941130001@slip-21-7.ots.utexas.edu>Show Full Headers
Complete Article Headers
Path: arc1-ca.pugleaf.net!ttk.a2i!ttk From: Bill Moyer <ttk@rahul.net> Newsgroups: comp.sys.powerpc,comp.sys.amiga.advocacy Subject: Re: Message passing speed on BeBox Date: 21 Nov 1995 16:05:08 GMT Organization: ZuulOS Development Labs Message-ID: <48stbk$pmv@hustle.rahul.net> References: <jazzDI1u41.16H@netcom.com> <ACD5092596684DB87@jake-6f.ip.realtime.net> <umisef.51.30B0765F@halls1.cc.monash.edu.au> <james-2011950941130001@slip-21-7.ots.utexas.edu> NNTP-Posting-Host: jive.rahul.net NNTP-Posting-User: ttk