Re: Can a CORBA server return a pointer to a GTK+ object?

On Sun, 14 Mar 1999, Russell Steinthal wrote:

> A question for the ORBit/CORBA gurus:
> Is there a way for a CORBA server to return a pointer to arbitrary 
> memory?  My gut tells me that that shouldn't be allowed (since it 
> would be next to impossible to extend to a remote server), and the 
> documentation I have found so far seems to confirm that...

Not that easily. Each application gets it's own virtual memory space, so
pointers passed between the two wouldn't make sense.

It was screwy enough when I did that on DOS :)

However you can use shared memory and accomplish the same basic goal.
Look at shmget(2), shmctl(2), and shmop(2) (there are a few other commands
too I think). 

> of new mail (via signals) which makes sense, but the CORBA server 
> needs to be able to give them references to the mailbox objects 
> somehow.  (They will be of various types derived from GnomeMailbox, 
> derived from GTKObject.)

I freely admit a fair amount of ignorance here, but can't you pass large
chunks of data through the CORBAServer? You could, in essence, define an
API to the GnomeMailbox, that the clients could use to view and modify it
without actually having a copy.

Mind you, I'm making all this up.

> The bottom line is probably: is there a way to allow clients to 
> receive notifications without requiring them to know there's CORBA 
> involved?  Or should I give in and require all mail-checkers be CORBA 
> clients simply specify a client-side CORBA interface which is called 
> when new mail arrives?  (I guess that makes the mailcheck clients 
> into mini-servers...)

I've been working on a project with a similiar design, and I provide a
named-pipe interface. A process can select(2) or gdk_add_input on a named
pipe easily enough. You can then pass a lot of data that way (entire mail
messages, if you wish :)

Chris Arguin                 | "...All we had were Zeros and Ones -- And            |  sometimes we didn't even have Ones."
                             +--------------+	- Dilbert, by Scott Adams |

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]