[NSWI080] HW 2 - questions

[Jakob Šalej]

Hi,

I have actually tried changing the parameters' order before, but I must
have done it incorrectly, because now it works.

Thank you for your assistance,
Jakob

V V pon., 1. apr. 2019 ob 14:58 je oseba Vlastimil Dort <
dort at d3s.mff.cuni.cz> napisala:

> Dear Jakob,
>
> the problem is most likely in the order of inputs passed to the linker.
> The -l flags should be specified after (not before) the .o files.
>
> Please try changing the server and client rules in the makefile, so that
> $(LIBFLAGS) comes at the end, like this:
>
> server: simpleSK.o server.o
>     $(CXX) $(CXXFLAGS) -o $@ $(LIBDIRFLAGS) $^ $(LIBFLAGS)
>
> client: simpleSK.o client.o
>     $(CXX) $(CXXFLAGS) -o $@ $(LIBDIRFLAGS) $^ $(LIBFLAGS)
>
> Sorry for the inconvenience.
>
> Vlastimil
> Dne 30.03.2019 v 19:27 Jakob Šalej napsal(a):
>
> Hi,
>
> I'm having problems compiling the given omniORB example on my private
> machine. It seems there is a problem with linked libraries (L
> /home/jakob/Apps/omniORB/lib -lomniORB4 -lomnithread -lomniDynamic4)  as I
> get a lot of "undefined reference" errors when I try to run *OMNIORB_HOME=~/Apps/omniORB
> make*. The omniORB directory should be linked correctly and it seems that
> all the required libs are there. Is there something obvious I'm missing?
>
> I'm using the precompiled omniORB binary from the course website, but I
> also tried compiling from source (but got the same errors). Running Ubuntu
> 16.04 and using *g++ (Ubuntu 5.4.0-6ubuntu1~16.04.11) 5.4.0 20160609. *The
> whole output from running the make command can be found here
> <https://pastebin.com/JASdj1Kw>.
>
> I'd appreciate any advice. Thank you,
> Jakob
>
> V V sob., 30. mar. 2019 ob 09:03 je oseba Vlastimil Dort <
> dort at d3s.mff.cuni.cz> napisala:
>
>> Dear Petr Šťavík,
>>
>>    1. The POA is synchronized internally by omniORB. You would need
>>    synchronization if you kept some non-local data. For example, you may store
>>    pointers to servants in a global container so that you can deallocate them
>>    later even if the client does not call the disconnect operation.
>>    2. You can observe the behavior of the provided server and implement
>>    your server to behave similarly. The purpose of the idle attribute is to
>>    show how readonly attributes are used and implemented. Although always
>>    returning true follows the protocol, it is not an interesting
>>    implementation, because then the client can get away with not checking the
>>    attribute at all. For example, our server starts returning true 5 seconds
>>    after creation of the instance. You could also use a counter to return true
>>    after a few times of returning false. Any implementation where the client
>>    has to wait a little bit and the server can check that the client waited
>>    would be great.
>>
>> Vlastimil Dort
>> Dne 29.03.2019 v 16:19 Petr Šťavík napsal(a):
>>
>> Hello, I have a few questions about the second assignment.
>>
>> Firstly - I don't really understand the following note in the task 6 "Do
>> not forget that with the default POA policy, methods of server_i are
>> executed in multiple threads and thus proper snychronization is required".
>> In my server implementation, there is no data that could be shared among
>> multiple threads, so I am not sure what to synchronize here. Maybe - do you
>> mean that we should synchronize access to the default CORBA structures like
>> POA table as they are not thread-safe (that means synchronizing method call
>> like _this() which registers the object)?
>>
>> Secondly - I am not sure how to implement few server methods, like the
>> Idle method. Instance returned to the client by connect method is exclusive
>> for that client, so it is always idle. Or am I getting something wrong?
>>
>> Thank you for your answers.
>>
>> --
>> S pozdravem Petr Šťavík
>>
>> _______________________________________________
>> NSWI080 mailing listNSWI080 at d3s.mff.cuni.czhttps://d3s.mff.cuni.cz/mailman/listinfo/nswi080
>>
>> _______________________________________________
>> NSWI080 mailing list
>> NSWI080 at d3s.mff.cuni.cz
>> https://d3s.mff.cuni.cz/mailman/listinfo/nswi080
>>
>
> _______________________________________________
> NSWI080 mailing listNSWI080 at d3s.mff.cuni.czhttps://d3s.mff.cuni.cz/mailman/listinfo/nswi080
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://d3s.mff.cuni.cz/pipermail/nswi080/attachments/20190402/2b332e2a/attachment.html>