Re: Crosscompiling ORBit2

[Guillermo Sanchez <guillersan gmail com>]

Hi Frank,

Thanks a lot for your answer. But I have no trouble in the stubs and
skels creation through idl compilation - After running the "echo"
example one hundred times i finally got it.

My troubles appears in the next stage when compiling the server,
client and skeleton implementation "classname-skelimp.c". I simply
don't know where the flags are applied or where the compilation is
done in the Makefile file. I know it has to be here:

       $(ORBIT_IDL) --skeleton-impl $^

But I don't know what is it doing or what's going on and I need to add
some flags.

The thread question comes because to use some RTAI funtions I have to
launch a couple of threads. Threads that aren't going to give a
response they will just be created, do their stuff in the server side
and be destroyed every time I need them.

Again thank you very much for the info.

Cheers,

Guillermo

2009/7/23 Frank Rehberger <Frank Rehberger web de>:
> Guillermo Sanchez wrote:
>> Hello collisters:
>>
>> I'm quite new in the ORBit world, so sorry if this is not the correct
>> way of asking things.
>>
>> I wanted to compile an ORBit program (server, client, skelimp...)
>> using RTAI flags (Real Time Aplication Interface) and includes, since
>> I'm using this last to communicate ORBit with a real time process. I
>> thought it would be a matter of makefile edition but when I edited it
>> I realized how new I'm in this world. Indeed I don't know where ORBit2
>> compiles at all.
>>
>>
> first you need to invoke the IDL compiler which generates the C code for
> your IDL interfaces, this way you will get the stubs and skeletons.
>
> $(IDLOUT): Uneje.idl
>        $(ORBIT_IDL) Uneje.idl
>
>
> The skeletons are for the server-side, the stubs for the client side.
>
> These files are ordinary C files which can be compiled to object files
> with gcc.
>
> On server side you will need also to implement the skeletons, commonly
> called "classname-skeleton-impl.c", which implement the logic of your
> server.
>
> Hope that helps.
>
>> By the way, is there any difference between using g_thread_create and
>> pthread_create?
>>
> little, g_thread_create will be mapped onto pthread_create, but for
> portability it is better to choose g_thread_create, which might also do
> some magic in background.
>
>> Also, can I create a thread inside the skeleton implementation code?
>>
> Off course you can, but if it is about to calculate a return value, you
> should not.
>
> Instead, the requests are managed by the POA, the portable object
> adapter. This Adapter will be initialized with so called
> concurrency-policy, which can be "single-threaded",
> "thread-per-connection" or a "system" specific threaded policy. AFAICS,
> thread per connection is the best choice for RealTime applications. This
> way each client (alias connection) would be associated with a specific
> thread on server side, and requests of high priorized clients would not
> share thread-resources with requests of low priorized threads. RT-CORBA
> defines a n umber of thread-pool features, but they are not implemented
> for ORBit2 yet (AFAIK).
>
> Regards, Frank
>