[NSWI080] HW 2 - questions

Vlastimil Dort dort at d3s.mff.cuni.cz
Mon Apr 1 14:57:49 CEST 2019


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 <mailto: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 list
>>     NSWI080 at d3s.mff.cuni.cz  <mailto:NSWI080 at d3s.mff.cuni.cz>
>>     https://d3s.mff.cuni.cz/mailman/listinfo/nswi080
>     _______________________________________________
>     NSWI080 mailing list
>     NSWI080 at d3s.mff.cuni.cz <mailto:NSWI080 at d3s.mff.cuni.cz>
>     https://d3s.mff.cuni.cz/mailman/listinfo/nswi080
>
>
> _______________________________________________
> NSWI080 mailing list
> NSWI080 at d3s.mff.cuni.cz
> https://d3s.mff.cuni.cz/mailman/listinfo/nswi080
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://d3s.mff.cuni.cz/pipermail/nswi080/attachments/20190401/a5b63658/attachment.html>


More information about the NSWI080 mailing list