SysV Ipc shm revisited...A new solution

SysV Ipc shm revisited...A new solution

[Nicholas Wourms]

Ok,

I hate to rehash an old discussion, but some private discussions with
Chuck have brought a new solution to light on an old problem.  Basically
we have a problem with certain applications requiring (or operating poorly
without) IPC.  It is quite evident that the new cygserver is a WIP -- very
unstable at the moment.  The only option was to use cygipc, which is a
fairly stable solution.  However, by doing so, your application would then
be dependant on the cygipc implimentation due to the 32bit vs. 64bit key
difference in cygipc and cygserver.  By enabling the 64bit key, all apps
built with a 32bit key would be broken when using the new cygserver. 
Obviously this has created quite a problem for many, as it doesn't provide
an easy solution when the key is switched over.  Anyhow, what we need is a
solution that provides reliable shared memory support in the main
distribution without the incompatibilities.  Furthermore, it would have to
be a solution which allowed switching between it and cygserver on the fly,
if necessary (to further testing of cygserver).  Here is the solution that
Chuck and I propose:

Distribute a package called cygipc-2:
1)It would contain a library libcygipc2.a which would be based on the
64bit key and compatible with cygserver's version.

2)ipc-daemon2.exe would peacefully co-exist with the cygserver.exe,
allowing a person to run either daemon (but not both) provided they had
turned on the 64bit key in cygwin.

Chuck says implimenting this package wouldn't be too much trouble, and is
willing to do so.  Now why, you ask, should we do so?  Simple, considier
all the dependancies it would satisfy.  Take, for example, X11, which is
currently compiled without SHM.  This, alone, prevents many of the more
advanced window managers from operating, not to mention some of the X11
applications which require shared memory.  However, with this solution,
Harold could rest assured that if he compiles X against cygipc2, it would
be compatible with cygserver, in its final form.  I'm sure there are many
more instances where this would be of use, but I think it comes down to
one point.  It removes the barrier for application development efforts,
while still allowing the continued testing and furtherment of the core
cygserver code.  It would provide a path for people to migrate to the 64
bit key, but at thier own pace.  This would be controlled by allowing
people to download 64bit key enabled snapshots, provided they had no
applications that were dependant on the legacy 32bit key enabled cygipc. 
Or, if they wanted to, they could compile the support in via a configure
option.  Then they could test the new cygserver, or if they found it too
unstable, revert to the cygipc2 server without having to change
cygwin1.dll's.  Choice is important, and is a the core of Free Software,
so why not give people more choices?  The fact is that the solution is
there, all Chuck needs is the green light...

Cheers,
Nicholas

__________________________________________________
Do You Yahoo!?
Yahoo! - Official partner of 2002 FIFA World Cup
http://fifaworldcup.yahoo.com

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: SysV Ipc shm revisited...A new solution

[Christopher Faylor]

On Thu, Jun 06, 2002 at 03:53:27PM -0700, Nicholas Wourms wrote:
>Distribute a package called cygipc-2:
>1)It would contain a library libcygipc2.a which would be based on the
>64bit key and compatible with cygserver's version.
>
>2)ipc-daemon2.exe would peacefully co-exist with the cygserver.exe,
>allowing a person to run either daemon (but not both) provided they had
>turned on the 64bit key in cygwin.

If Robert and Chuck agree, I have no problems.  We'd have to make sure
that there are no gotchas if/when cygserver is released.

Is anyone actually attempting to get cygserver working with shm, though?

cgf

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: SysV Ipc shm revisited...A new solution

[Charles Wilson]

I'm reading this thread top-down, so if I say something that has already 
been addressed in a different followup to Nicholas's message, I 
apologize for the repetition.  If, as I read down this thread, I see 
something that I've addressed in THIS reply, I will NOT make an explicit 
reply that says "I addressed this point in my original message".  So, 
read THIS message carefully...

If there were any misunderstandings between Nicholas and I, no worries 
from my end.  He's not talking out of school...but merely expanding on a 
single sentence in a private email.  I encouraged him to do so -- but 
it's possible he "expanded" in a direction I didn't intend.  But that's 
okay...

Nicholas Wourms wrote:

[background snipped]

 
> Distribute a package called cygipc-2:
> 1)It would contain a library libcygipc2.a which would be based on the
> 64bit key and compatible with cygserver's version.

> 
> 2)ipc-daemon2.exe would peacefully co-exist with the cygserver.exe,
> allowing a person to run either daemon (but not both) provided they had
> turned on the 64bit key in cygwin.


Sortof.  In my view, cygipc-2 would NOT be an official part of the 
cygwin dist.  It would, just like the current cygipc, live over on the 
cygutils website.  BUT, it would be compatible with the 64bit keysize 
used be cygdaemon.  That way, if for instance Jason recompiled postgres 
against cygipc2, then (hopefully) folks could use THAT version of 
postgres with EITHER ipcdaemon2 OR cygdaemon, without having to 
recompile postgres (and NOT having to recompile their kernel).

This would enable testing of the new cygdaemon with existing code -- but 
still would "keep the heat on" for a stable cygdaemon, since cygipc2 is 
STILL not a real part of the cygwin dist.

> Chuck says implimenting this package wouldn't be too much trouble, and is
> willing to do so.  Now why, you ask, should we do so?  Simple, considier
> all the dependancies it would satisfy.  Take, for example, X11, which is
> currently compiled without SHM.  This, alone, prevents many of the more
> advanced window managers from operating, not to mention some of the X11
> applications which require shared memory.  However, with this solution,
> Harold could rest assured that if he compiles X against cygipc2, it would
> be compatible with cygserver, in its final form. 


Okay, this part I disagree with.  The *only* extant exception, where an 
official cygwin package is allowed to depend on a non-cygwin package, is 
postgres.  I don't want to add X to that list, and I don't want cygipc2 
to be an official cygwin package.

I just want to make it easier for people to TEST stuff against cygdaemon 
-- IF they want to do so.  By mandating that Harold compile his X 
packages against cygipc2 (or cygdaemon) we then REQUIRE everybody who 
wants to run X to install an IPC daemon.  Currently, the only fully (?!) 
functional one is cygipc(2?).

But that is not an official package.  I don't want to make it an 
official package.

In my view, with the "new" cygipc2 off-site package, interested parties 
like the KDE folks can recompile X -- like they are doing now.  BUT, if 
they do so, then they could cleanly SWITCH between cygipc2 and cygdaemon 
without a SECOND recompile.

> I'm sure there are many
> more instances where this would be of use, but I think it comes down to
> one point.  It removes the barrier for application development efforts,


True -- and not a good thing.  I *want* that barrier -- because its 
presense serves as a painful reminder to HELP GET CYGDAEMON WORKING!!! <g>


> while still allowing the continued testing and furtherment of the core
> cygserver code.  It would provide a path for people to migrate to the 64
> bit key, but at thier own pace.


Not entirely true.  It would FORCE people who want to use X to install 
an extra package, and run a background daemon.  Lots of folks don't want 
to do that...like me. <g>

[snip]

> Then they could test the new cygserver, or if they found it too
> unstable, revert to the cygipc2 server without having to change
> cygwin1.dll's. 


Yep.  But in my view, no official cygwin packages except for postgres, 
would depend on cygipc2.  If you want to play with ipcdaemon/cygdaemon, 
you still need to compile your app with the appropriate flags to do so. 
  Even if that app happens to all of XFree86.

--Chuck


--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

RE: SysV Ipc shm revisited...A new solution

[Robert Collins]

> -----Original Message-----
> From: cygwin-owner@cygwin.com 
> [mailto:cygwin-owner@cygwin.com] On Behalf Of Charles Wilson
> Sent: Saturday, 8 June 2002 1:09 AM

> That way, if for instance Jason 
> recompiled postgres 
> against cygipc2, then (hopefully) folks could use THAT version of 
> postgres with EITHER ipcdaemon2 OR cygdaemon, without having to 
> recompile postgres (and NOT having to recompile their kernel).

Nup. Not going to work (see my other email). However, in -no- scenario
is kernel recompilation needed, once cygwin1.dll comes with the exports
enabled. That's orthogonal to the current discussion on co-existence
though.
 
Rob


--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Debugging SysV IPC

[Nicholas Wourms]

> Nup. Not going to work (see my other email). However, in -no- scenario
> is kernel recompilation needed, once cygwin1.dll comes with the exports
> enabled. That's orthogonal to the current discussion on co-existence
> though.
>  
> Rob

Ok, new question, is there a particular way you would like to have me run
gdb/strace so that I can capture the information which is most relevant to
YOU?  Should I do so on the entire test suite?  This is only way I can
help, sorry, as my knowledge of SysV IPC is virtually non-existant and my
learning plate is quite full atm, though I intend to learn as I go.  I
still want to help, so I offer to test it on my platform (WindowsME) and
report back with the debugging output which is best suited for your needs.
 Yes, I *know* these commands are documented, its just that I want my
reports to be relevant and easy for you to disseminate the cause of the
problem.  Thanks for clarifying this for me...and for any other potential
testers out there.

Cheers,
Nicholas

__________________________________________________
Do You Yahoo!?
Yahoo! - Official partner of 2002 FIFA World Cup
http://fifaworldcup.yahoo.com

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

RE: Debugging SysV IPC

[Robert Collins]

> -----Original Message-----
> From: cygwin-owner@cygwin.com 
> [mailto:cygwin-owner@cygwin.com] On Behalf Of Nicholas Wourms
> Sent: Saturday, 8 June 2002 3:01 AM
> To: Robert Collins
> Cc: cygwin@cygwin.com
> Subject: Debugging SysV IPC
> 
> 
> > Nup. Not going to work (see my other email). However, in 
> -no- scenario
> > is kernel recompilation needed, once cygwin1.dll comes with 
> the exports
> > enabled. That's orthogonal to the current discussion on co-existence
> > though.
> >  
> > Rob
> 
> Ok, new question, is there a particular way you would like to 
> have me run
> gdb/strace so that I can capture the information which is 
> most relevant to
> YOU?  Should I do so on the entire test suite?  This is only way I can
> help, sorry, as my knowledge of SysV IPC is virtually 
> non-existant and my
> learning plate is quite full atm, though I intend to learn as I go.  I
> still want to help, so I offer to test it on my platform 
> (WindowsME) and
> report back with the debugging output which is best suited 
> for your needs.
>  Yes, I *know* these commands are documented, its just that I want my
> reports to be relevant and easy for you to disseminate the 
> cause of the
> problem.  Thanks for clarifying this for me...and for any 
> other potential
> testers out there.

If gdb/strace is needed, I'll ask for specific info at the time. At the
moment, IIRC you have an issue with the cygserver (apparently) not
running when you start it. You need to look in the source
(cygserver_transport_sockets) and find the domain socket file that
should be created, and 
* kill cygserver
* remove the file
* start cygserver

And see if that fixes it. If it doesn't, then gdb is your friend. Don't
worry about getting cygwin to connect to the cygserver, just find out
why it's not (apparently) listening. Oh, also in the cygserver source
files, change DEBUG to 1 and it'll spew debugging data to strace (for
API calls) and to the console (for cygserver).

Rob


--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

RE: SysV Ipc shm revisited...A new solution

[Robert Collins]

> -----Original Message-----
> From: cygwin-owner@cygwin.com 
> [mailto:cygwin-owner@cygwin.com] On Behalf Of Nicholas Wourms
> Sent: Friday, 7 June 2002 8:53 AM


> It is quite evident that the new cygserver is 
> a WIP -- very
> unstable at the moment.  

Yup. Actually the cgyserver itself is quite stable, it's the IPC code
that is bleeding edge at the moment. (IMO).

> The only option was to use cygipc, which is a
> fairly stable solution.  However, by doing so, your 
> application would then
> be dependant on the cygipc implimentation due to the 32bit 
> vs. 64bit key
> difference in cygipc and cygserver.  

There is much more than that to the difference. At a minimum the link
library and/or dll import is an issue, at maximum the RPC style used to
talk to the daemon is an issue. Unless the RPC stubs for cygserver and
cygipc are identical - which they are not irrespective of the key_t size
- you will always have to relink your application when you switch from
one IPC server to another. Mind you, they can co-exist and run at the
same time.

> Furthermore, it 
> would have to
> be a solution which allowed switching between it and 
> cygserver on the fly,
> if necessary (to further testing of cygserver).  Here is the 
> solution that
> Chuck and I propose:

That is already available and documented - to the extent that it is
physically possible. (i.e. 
(Boot;
Start cygserver;
Start cygipc;
While testing do{
A) switch types.h;sem.h;shm.h;ipc.h; to appropriate copy.
B) rebuild your app.
C) test it.
}
 
> Distribute a package called cygipc-2:
> 1)It would contain a library libcygipc2.a which would be based on the
> 64bit key and compatible with cygserver's version.

Ok. This is doable, but won't reduce the headaches above.
 
> 2)ipc-daemon2.exe would peacefully co-exist with the cygserver.exe,
> allowing a person to run either daemon (but not both) 
> provided they had
> turned on the 64bit key in cygwin.

They can already run both. I've tested this BTW.
 
> Chuck says implimenting this package wouldn't be too much 
> trouble, and is
> willing to do so.  Now why, you ask, should we do so?  
> Simple, considier
> all the dependancies it would satisfy.  Take, for example, 
> X11, which is
...
> one point.  It removes the barrier for application 
> development efforts,

Nope. It doesn't. Nice try though, and I'm sorry it won't work.

> while still allowing the continued testing and furtherment of the core
> cygserver code.  It would provide a path for people to 
> migrate to the 64
> bit key, but at thier own pace.  

Already provided. What will happen when the 64 bit key is exported is
that fresh cygipc linked programs will fail, but existing programs will
still work correctly. If something like ipcdaemon2.exe exists - OR -
cygipc is re-released as a 64-bit version, then new links will succeed
(but at the possible cost of breaking old binaries). 

Rob


--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

RE: SysV Ipc shm revisited...A new solution

[Ralf Habacker]

>Robert Collins wrote:

> Already provided. What will happen when the 64 bit key is exported is
> that fresh cygipc linked programs will fail, but existing programs will
> still work correctly. If something like ipcdaemon2.exe exists - OR -
> cygipc is re-released as a 64-bit version, then new links will succeed
> (but at the possible cost of breaking old binaries).
>
Why must this be ? Could not the released 64-bit version only use the most
significant long word of key_t, so that it is compatible to the old binaries and
can use the 64 bit key_t definition ?

Ralf


--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

RE: SysV Ipc shm revisited...A new solution

[Robert Collins]

> -----Original Message-----
> From: Ralf Habacker [mailto:Ralf.Habacker@freenet.de] 
> Sent: Saturday, 8 June 2002 5:19 AM
> To: Robert Collins; 'Nicholas Wourms'; cygwin@cygwin.com
> Cc: cwilson@ece.gatech.edu
> Subject: RE: SysV Ipc shm revisited...A new solution
> 
> 
> >Robert Collins wrote:
> 
> > Already provided. What will happen when the 64 bit key is 
> exported is
> > that fresh cygipc linked programs will fail, but existing 
> programs will
> > still work correctly. If something like ipcdaemon2.exe exists - OR -
> > cygipc is re-released as a 64-bit version, then new links 
> will succeed
> > (but at the possible cost of breaking old binaries).
> >
> Why must this be ? Could not the released 64-bit version only 
> use the most
> significant long word of key_t, so that it is compatible to 
> the old binaries and
> can use the 64 bit key_t definition ?

It wouldn't be compatible with the old binaries because the signature
would still be wrong, and this would lead to immediate crashes when it
tried to pop to much off the stack.

Rob


--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: SysV Ipc shm revisited...A new solution

[Charles Wilson]

Robert Collins wrote:

> There is much more than that to the difference. At a minimum the link
> library and/or dll import is an issue, at maximum the RPC style used to
> talk to the daemon is an issue. Unless the RPC stubs for cygserver and
> cygipc are identical - which they are not irrespective of the key_t size
> - you will always have to relink your application when you switch from
> one IPC server to another. Mind you, they can co-exist and run at the
> same time.


Okay, yeah -- you'll always have to reLINK your application when 
switching between the two servers.  But if both cygdaemon and cygipc2 
use a 64 bit key, then at least you won't have to reCOMPILE your source 
code...right?

The RPC function signatures are identical...nope, they aren't.  Neither 
are the structures...I think this means you'll always have to reCOMPILE 
client source code in addition to reLINKing it.

example: char * vs. const void *, int vs size_t

cygdaemon:
void *shmat(int, const void *, int);
int   shmctl(int, int, struct shmid_ds *);
int   shmdt(const void *);
int   shmget(key_t, size_t, int);

ipcdaemon:
char *shmat (int shmid, char *shmaddr, int shmflg);
int shmctl (int shmid, int cmd, struct shmid_ds *buf);
int shmdt (char *shmaddr);
int shmget (key_t key, int size, int flag);

Also, the ipcdaemon structure shmid_ds has some extra fields, as 
compared to the cygdaemon version -- and even the fields that they have 
in common are in different orders.


> That is already available and documented - to the extent that it is
> physically possible. (i.e. 
> (Boot;
> Start cygserver;
> Start cygipc;
> While testing do{
> A) switch types.h;sem.h;shm.h;ipc.h; to appropriate copy.
> B) rebuild your app.
> C) test it.


>>Distribute a package called cygipc-2:
>>1)It would contain a library libcygipc2.a which would be based on the
>>64bit key and compatible with cygserver's version.
>>
> 
> Ok. This is doable, but won't reduce the headaches above.


Actually, a 64bit-key_t-using libcygipc2 would mean that you don't need 
to "switch" types.h.  Just sem/shm/msg/ipc.h -- which is as easy as 
adding -I/usr/local/include to CFLAGS or not.

But, it seems as though there are LOTS of differences between the 
cygdaemon implementation and the ipcdaemon implementation (this is good, 
because frankly, ipcdaemon sucks).

So you'll ALWAYS have to recompile and relink your app when switching 
between ipcdaemon on cygdaemon.

<rhetorical>
So what was all the fuss about 32bits versus 64bits on key_t?  Seems 
like that's just a drop in the ocean of differences...

Ah! the fuss was because "key_t" is defined in newlib's types.h file -- 
which will almost always get included when compiling ipc programs.  But 
this definition conflicts with what the CURRENT libcygipc.a and 
ipcdaemon.exe think...so newly compiled, cygipc-based apps will ALWAYS 
break (at runtime maybe, but more probably at linktime due to 
conflicting definitions)...more below.
</rhetorical>


> They can already run both. I've tested this BTW.


And the sensei speaks...


> Already provided. What will happen when the 64 bit key is exported is
> that fresh cygipc linked programs will fail, 


because the new program, even though it uses libcygipc, will see the 
cygdaemon-inspired newlib 64bit definition for key_t, but ipcdaemon 
itself, running in the background, will think that key_t is 32bits -- 
because it was built before newlib defined key_t.  Mismatch between 
client and server == crash.  Okay, I get that.

> but existing programs will
> still work correctly. 


Right, because both were compiled back before the cygdaemon-inspired 
change to newlib's types.h which declared key_t to be a 64bit value.

> If something like ipcdaemon2.exe exists - OR -
> cygipc is re-released as a 64-bit version, then new links will succeed


because the daemon and the newly-build client and libcygipc2 library, 
will all agree that key_t is 64 bits.


> (but at the possible cost of breaking old binaries). 


Right -- maybe.  old binaries will try to talk to ipcdaemon -- but 
unless I change the handle ID strings (in IpcNtLit.h), both ipcdaemon 
and ipcdaemon2 will answer the same requests -- but one will "know" that 
the key_t is 32, but the other deamon will think that key_t is 64bits == 
boom.

So, I'd need to insure that
   1) ipc-daemon.exe and ipc-daemon2.exe can coexist
     --> change the ID strings and filenames in IpcNtLit.h, so that new 
programs use a different ID string when contacting the server, and the 
new server answers to that new ID string.
   2) teach ipc-daemon2 (and libcygipc2) that key_t is 64 bits.

However, in this scenario, there's really no reason for the library name 
to change.  (But the daemon name MUST change).  The old library, the 
current libcygipc.a, will be completely useless after cygwin-1.3.11 is 
released.  So, I might as well let the new (functional) library be 
libcygipc.a -- that way, existing programs that use libcygipc.a can 
still -lcygipc and won't need to change their build process to -lcygipc2 
or somesuch.  But, so that people can have both cygipc daemons 
running/installed on the same system, the daemon name must be different.

Furthermore, this modification of the cygipc interface is not "so that 
people can switch between cygipc and cygdaemon versions easily" -- that 
still won't be easy, unfortunately.  The mod is necessary "so that you 
can actually build and link cygipc programs under cygwin-1.3.11".

Did I get that right, sensei?

--Chuck


--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

RE: SysV Ipc shm revisited...A new solution

[Robert Collins]

> -----Original Message-----
> From: cygwin-owner@cygwin.com 
> [mailto:cygwin-owner@cygwin.com] On Behalf Of Charles Wilson
> Sent: Saturday, 8 June 2002 6:38 AM


> Ah! the fuss was because "key_t" is defined in newlib's 
> types.h file -- 
> which will almost always get included when compiling ipc 
> programs.  But 
> this definition conflicts with what the CURRENT libcygipc.a and 
> ipcdaemon.exe think...so newly compiled, cygipc-based apps 
> will ALWAYS 
> break (at runtime maybe, but more probably at linktime due to 
> conflicting definitions)...more below.
> </rhetorical>
 
Exactly.
 
> So, I'd need to insure that
>    1) ipc-daemon.exe and ipc-daemon2.exe can coexist
>      --> change the ID strings and filenames in IpcNtLit.h, 
> so that new 
> programs use a different ID string when contacting the 
> server, and the 
> new server answers to that new ID string.
>    2) teach ipc-daemon2 (and libcygipc2) that key_t is 64 bits.
> 
> However, in this scenario, there's really no reason for the 
> library name 
> to change.  (But the daemon name MUST change).  The old library, the 
> current libcygipc.a, will be completely useless after 
> cygwin-1.3.11 is 
> released.  So, I might as well let the new (functional) library be 
> libcygipc.a -- that way, existing programs that use libcygipc.a can 
> still -lcygipc and won't need to change their build process 
> to -lcygipc2 
> or somesuch.  But, so that people can have both cygipc daemons 
> running/installed on the same system, the daemon name must be 
> different.
> 
> Furthermore, this modification of the cygipc interface is not 
> "so that 
> people can switch between cygipc and cygdaemon versions 
> easily" -- that 
> still won't be easy, unfortunately.  The mod is necessary "so 
> that you 
> can actually build and link cygipc programs under cygwin-1.3.11".
> 
> Did I get that right, sensei?

The student is learning.

Rob


--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

RE: SysV Ipc shm revisited...A new solution

[Robert Collins]

> -----Original Message-----
> From: cygwin-owner@cygwin.com 
> [mailto:cygwin-owner@cygwin.com] On Behalf Of Nicholas Wourms
> Sent: Friday, 7 June 2002 8:53 AM


> It is quite evident that the new cygserver is 
> a WIP -- very
> unstable at the moment.  

Yup. Actually the cgyserver itself is quite stable, it's the IPC code
that is bleeding edge at the moment. (IMO).

> The only option was to use cygipc, which is a
> fairly stable solution.  However, by doing so, your 
> application would then
> be dependant on the cygipc implimentation due to the 32bit 
> vs. 64bit key
> difference in cygipc and cygserver.  

There is much more than that to the difference. At a minimum the link
library and/or dll import is an issue, at maximum the RPC style used to
talk to the daemon is an issue. Unless the RPC stubs for cygserver and
cygipc are identical - which they are not irrespective of the key_t size
- you will always have to relink your application when you switch from
one IPC server to another. Mind you, they can co-exist and run at the
same time.

> Furthermore, it 
> would have to
> be a solution which allowed switching between it and 
> cygserver on the fly,
> if necessary (to further testing of cygserver).  Here is the 
> solution that
> Chuck and I propose:

That is already available and documented - to the extent that it is
physically possible. (i.e. 
(Boot;
Start cygserver;
Start cygipc;
While testing do{
A) switch types.h;sem.h;shm.h;ipc.h; to appropriate copy.
B) rebuild your app.
C) test it.
}
 
> Distribute a package called cygipc-2:
> 1)It would contain a library libcygipc2.a which would be based on the
> 64bit key and compatible with cygserver's version.

Ok. This is doable, but won't reduce the headaches above.
 
> 2)ipc-daemon2.exe would peacefully co-exist with the cygserver.exe,
> allowing a person to run either daemon (but not both) 
> provided they had
> turned on the 64bit key in cygwin.

They can already run both. I've tested this BTW.
 
> Chuck says implimenting this package wouldn't be too much 
> trouble, and is
> willing to do so.  Now why, you ask, should we do so?  
> Simple, considier
> all the dependancies it would satisfy.  Take, for example, 
> X11, which is
...
> one point.  It removes the barrier for application 
> development efforts,

Nope. It doesn't. Nice try though, and I'm sorry it won't work.

> while still allowing the continued testing and furtherment of the core
> cygserver code.  It would provide a path for people to 
> migrate to the 64
> bit key, but at thier own pace.  

Already provided. What will happen when the 64 bit key is exported is
that fresh cygipc linked programs will fail, but existing programs will
still work correctly. If something like ipcdaemon2.exe exists - OR -
cygipc is re-released as a 64-bit version, then new links will succeed
(but at the possible cost of breaking old binaries). 

Rob


--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/