Re: [boost] libzeep

Subject: Re: [boost] libzeep
From: Maarten L. Hekkelman (m.hekkelman_at_[hidden])
Date: 2010-04-14 02:12:38

Op 14-04-10 00:21, Juraj Ivančić schreef:

> I wanted to give it a try but unfortunately it does not compile on
> windows. A little peeking around the code showed that there was some
> fork() calls as well as some unix specific IPC (socketpair). Also, ASIOs
> native_socket_type is used in some places. Is there any special reason
> for this? You are already using asio and great deal of boost, why not go
> all the way and be portable? I'd be glad to help here if I can.

It is an option to use this. I should put that code in some 
conditionally compiled part, I agree. There is also a plain vanilla 
version of the server code that uses boost::asio only.

> Just out of curiosity - why does HTTP server spawn a worker process? Is
> it merely 'the unix way of doing things' or does it improve performance
> compared to keeping everything intraprocess?

That's because I have a server process running at our computer that 
serves several SOAP services to search biological and medical databanks. 
Some of these databanks are available worldwide while others are 
strictly for internal use. Now I have one main server process that forks 
several sub processes. These sub processes cannot access each others 
memory and so we keep the sensitive data separated from the worldwide data.

Another huge advantage is that I can detect from the master process when 
a child dies (which can happen since it starts other sub processes 
itself). Now I can restart a client from the master and I don't have to 
have another way to monitor the entire server. And so the server process 
is started at boot time and continues running until the next reboot 
serving thousands of requests per day.

> As an interesting side note - while attempting to compile libzeep I
> found that VS 9.0 compiler does not recognize spelled logical operators
> ('or', 'not' and 'and') as C++ keywords. Furthermore, passing macros
> like or=|| on the VS command line causes internal compiler error.
> Putting them inside code as #defines is OK for VS, but gcc (correctly)
> refuses to preprocess this.

I used to have those defined in code that was meant to compile on 
windows. I personally believe my code is much more readable with the 
textual operators.

Thanks,

-maarten