Thread: BeOS and IPC - try 999
OK, so this isn't try 999 but it feels like it! One of the arguments that Tom came up with for not liking the patches was that (paraphrasing) "the patches make maintainenace harder and don't add anything that could help other non-unix platforms" OK, agreed (up to a point). So, you want easier maintenance? The ONLY way that I can think of doing it is to have the platform specific IPC stuff in it's own file, hence this patch. The core functions, the ones that have no platform specific code in them, still live in ipc.c but all the functions that are touched by platform code live in either ipc_unix.c or ipc_beos.c. Using this there's no reason why other platforms can't do the same. Even native windows functions could be written using the split and the code should be easily maintainable by the people for each platform. It's simple and the code very readable. The setup could be used to help other non-unix platforms. I'm not sure what else I can do if this isn't OK?! The attached has new files for the ipc code with a beos and unix specific file. I'll add a note of caution that while this all works on BeOS I've not tested it on a unix platform. david "I never get involved in my own life, it's way too complicated."
On Wed, 14 Jun 2000, David Reid wrote: > OK, so this isn't try 999 but it feels like it! > > One of the arguments that Tom came up with for not liking the patches > was that > > (paraphrasing) > "the patches make maintainenace harder and don't add anything that could > help other non-unix platforms" > > OK, agreed (up to a point). So, you want easier maintenance? The ONLY > way that I can think of doing it is to have the platform specific IPC > stuff in it's own file, hence this patch. The core functions, the ones > that have no platform specific code in them, still live in ipc.c but all > the functions that are touched by platform code live in either > ipc_unix.c or ipc_beos.c. Using this there's no reason why other > platforms can't do the same. Even native windows functions could be > written using the split and the code should be easily maintainable by > the people for each platform. This sounds reasonable to me ... or am I overlooking something obvious?
"David Reid" <david@jetnet.co.uk> writes:
> OK, agreed (up to a point). So, you want easier maintenance? The ONLY
> way that I can think of doing it is to have the platform specific IPC
> stuff in it's own file, hence this patch. The core functions, the ones
> that have no platform specific code in them, still live in ipc.c but all
> the functions that are touched by platform code live in either
> ipc_unix.c or ipc_beos.c.
This is a step forward from what you had, for sure. I'm not sure if
the separate-files approach is really good, though, compared to
a pattern like
int IPCFunction()
{
#ifdef BEOS
BEOS code
#else
unix code
#endif
}
for each function. The thing that scares me about separate files
is the out-of-sight, out-of-mind problem: if you make a change
in one file, will you remember to update the corresponding code
in the other files (if there is any)?
OTOH the code for each platform is certainly cleaner this way.
Comments anyone?
regards, tom lane
On Wed, Jun 14, 2000 at 12:35:44PM -0400, Tom Lane wrote:
> "David Reid" <david@jetnet.co.uk> writes:
> > OK, agreed (up to a point). So, you want easier maintenance? The ONLY
> > way that I can think of doing it is to have the platform specific IPC
> > stuff in it's own file, hence this patch. The core functions, the ones
> > that have no platform specific code in them, still live in ipc.c but all
> > the functions that are touched by platform code live in either
> > ipc_unix.c or ipc_beos.c.
>
> This is a step forward from what you had, for sure. I'm not sure if
> the separate-files approach is really good, though, compared to
> a pattern like
>
> int IPCFunction()
> {
> #ifdef BEOS
> BEOS code
> #else
> unix code
> #endif
> }
>
> for each function. The thing that scares me about separate files
> is the out-of-sight, out-of-mind problem: if you make a change
> in one file, will you remember to update the corresponding code
> in the other files (if there is any)?
> Comments anyone?
Hrm--we already do this sort of thing for the dynaloader
functions, I assume for much the same reason (very different
interfaces on different systems). It is also somewhat unlikely
that someone modifying the IPC API for one system is going to
be able (or at least willing) to update the functions for other
platforms. On the other hand, basic IPC hasn't changed much
from semaphore/shared memory for quite a while.
--
Adam Haberlach |"You have to understand that the
adam@newsnipple.com | entire 'Net is based on people with
http://www.newsnipple.com/ | too much free time on their hands."
David Reid writes:
> OK, agreed (up to a point). So, you want easier maintenance? The ONLY
> way that I can think of doing it is to have the platform specific IPC
> stuff in it's own file, hence this patch.
What I was thinking about is that you essentially create a wrapper library
of SysV-like functions that call the BEOS-specific functions, like
int
semctl(int semid, int semnum, int cmd, union semun arg)
{
switch (cmd)
{
case IPC_RMID:
delete_sem(semid);
break;
...
}
}
int
semget(key_t key, int nsems, int semflg)
{
create_sem(...);
}
etc. That way there's essentially zero maintenance overhead for both the
Unix and the Beos factions. And you'd be doing yourself and the world a
big favour when you're trying to port the next IPC heavy program.
--
Peter Eisentraut Sernanders väg 10:115
peter_e@gmx.net 75262 Uppsala
http://yi.org/peter-e/ Sweden
> etc. That way there's essentially zero maintenance overhead for both the > Unix and the Beos factions. And you'd be doing yourself and the world a > big favour when you're trying to port the next IPC heavy program. OK. I've ported about 10 apps to BeOS and have done a lot of work on code for multi-platform interfaces and most have had IPC of some description or other - none have required writing an IPC emulation library!!! Why do you think it'll be zero maintenance? Sorry that argument goes way over my head... I mean if I write enough of an IPC emulation so it works today and you change the code to add a feature I haven't put in, it's broken isn't it? Maybe if I had unlimited time then I could write the library with every single function it could ever need, but practise shows that's unlikely. semctl and friends isn't the be all and end all. Wrapping it can be done, but as the beos code is far simpler, why? Tom said he wanted a way that "other non-unix" platforms could hook into pgsql. Having to write wrappers for unix api's isn't it going to help that. I dislike the wrapper approach as it provides a false level of comfort. I'm a firm believer that when you port, the best way is to have the code for the platform in the cleanest form possible and that's what I thought this patch achieved. If the criteria for getting code into your tree is that it "looks like what we use" then I guess I can accept that, but why didn't you say sooner? I guess when I get time I'll maybe look at it again but I have other things to do that people seem to appreciate and want. Sorry to be negative, but that's how I feel. :( david > > > -- > Peter Eisentraut Sernanders väg 10:115 > peter_e@gmx.net 75262 Uppsala > http://yi.org/peter-e/ Sweden > >
Okay, I think the concept might revolve around idea of having some sort of 'libipc' for BEOS that created the map'ngs to Unix equivalents ... then you could take any Unix based program that used IPC and compile it just by adding -lipc to it ... its even a test we could easily add to our configure checks ... ... but, personally, I think I've lost the whole point of this ... we do the whole dynloader stuff based on 'a different *file* per operating system' and its worked quite well ... what is the big issue about having a 'unix_ipc.c', 'beos_ipc.c' and 'win_ipc.c' (if needed) and usin whichever one as appropriate? It would be a simple configure check ... Would it break something that I'm overlooking? As long as the Unix developers are properly maintaining the unix_ipc.c variant, and someone from the BEOS world (David, say) was maintaining the beos_ipc.c, who cares? David, I think that a BEOS libipc_unix.a, or something like that, that could be link'd against for IPC emulation would be cool, and might make porting those 10 other apps you've done easier ... ... but, if time isn't something you have much of, could you send me a *clean* patch against the current source tree to look over? I think this whole discussion has gotten way out of proportion and everyone is getting frustrated ... On Fri, 16 Jun 2000, David Reid wrote: > > etc. That way there's essentially zero maintenance overhead for both the > > Unix and the Beos factions. And you'd be doing yourself and the world a > > big favour when you're trying to port the next IPC heavy program. > > OK. I've ported about 10 apps to BeOS and have done a lot of work on code > for multi-platform interfaces and most have had IPC of some description or > other - none have required writing an IPC emulation library!!! Why do you > think it'll be zero maintenance? Sorry that argument goes way over my > head... I mean if I write enough of an IPC emulation so it works today and > you change the code to add a feature I haven't put in, it's broken isn't it? > Maybe if I had unlimited time then I could write the library with every > single function it could ever need, but practise shows that's unlikely. > > semctl and friends isn't the be all and end all. Wrapping it can be done, > but as the beos code is far simpler, why? Tom said he wanted a way that > "other non-unix" platforms could hook into pgsql. Having to write wrappers > for unix api's isn't it going to help that. > > I dislike the wrapper approach as it provides a false level of comfort. I'm > a firm believer that when you port, the best way is to have the code for the > platform in the cleanest form possible and that's what I thought this patch > achieved. > > If the criteria for getting code into your tree is that it "looks like what > we use" then I guess I can accept that, but why didn't you say sooner? I > guess when I get time I'll maybe look at it again but I have other things to > do that people seem to appreciate and want. Sorry to be negative, but > that's how I feel. :( > > david > > > > > > > -- > > Peter Eisentraut Sernanders v�g 10:115 > > peter_e@gmx.net 75262 Uppsala > > http://yi.org/peter-e/ Sweden > > > > > Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy Systems Administrator @ hub.org primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org
The Hermit Hacker writes: > we do the whole dynloader stuff based on 'a different *file* per > operating system' and its worked quite well Most of these files are duplicates or kind of empty or some such. A little more flexibility would be nice. There are also a couple of subtle technical problems with AC_LINK_FILES in Autoconf which would lead me to suggest that, "Given a tie, don't do it." Why not ipc.c: #ifdef __BEOS__ /* BEOS stuff */ #elif defined(__FOONIX__) /* FooNix stuff */ #else /* "normal" stuff */ #endif /* common stuff */ i.e., everything in one file but separated by system. That would also eliminate the need for duplicating stuff that could be used across the board. > Would it break something that I'm overlooking? As long as the Unix > developers are properly maintaining the unix_ipc.c variant, and someone > from the BEOS world (David, say) was maintaining the beos_ipc.c, who > cares? In practice people also do error message rephrasing, include file cleanups, function prototype changes, add or remove global variables, change defines to enums, update comments, etc. There are also a couple of things in ipc.c that are common to all implementations, so those would be just waiting to fall out of sync. I've seen stuff getting out of whack with reality in the *same* file because it was #ifdef EXOTIC_FEATURE, so I'd agree with Tom to keep things "in sight" as much as possible. > I think this whole discussion has gotten way out of proportion and > everyone is getting frustrated ... If everyone got "frustrated" if people offer ideas then we'd never get anywhere. *shrug* -- Peter Eisentraut Sernanders väg 10:115 peter_e@gmx.net 75262 Uppsala http://yi.org/peter-e/ Sweden