headers
Wolfgang Sourdeau | 11 Dec 2008 18:28
Picon

multi-threaded design in SOPE

Hi,

We have discovered that the SOPE base application objects were somewhat 
"ready" for multi-threaded apps, in the sense that code has been written 
with this design in mind. So I was wondering how functional it was?

Running a simple basic test gave me this output:
2008-12-11 12:20:10.393 sogod-0.9[17890] autorelease called without pool 
for object (324f090) of class NSUIntNumber in thread <NSThread: 0x3138460>
2008-12-11 12:20:10.393 sogod-0.9[17890] autorelease called without pool 
for object (324f0c0) of class NSUIntNumber in thread <NSThread: 0x3138460>
2008-12-11 12:20:10.393 sogod-0.9[17890] autorelease called without pool 
for object (324f0f0) of class NSUIntNumber in thread <NSThread: 0x3138460>
2008-12-11 12:20:10.393 sogod-0.9[17890] autorelease called without pool 
for object (324f120) of class NSUIntNumber in thread <NSThread: 0x3138460>
....

But the SOGo process still seemed to perform correctly. Is that just a 
matter of tweaking things a little bit?

-- 
Wolfgang Sourdeau   ::   +1 (514) 755-3520   ::   wsourdeau@...

--

-- 
OpenGroupware.org Developer
developer@...
http://mail.opengroupware.org/mailman/listinfo/developer
Permalink | Reply | 5 comments |
headers
Helge Hess | 11 Dec 2008 19:25
Favicon

Re: multi-threaded design in SOPE

On 11.12.2008, at 18:28, Wolfgang Sourdeau wrote:
> We have discovered that the SOPE base application objects were  
> somewhat "ready" for multi-threaded apps, in the sense that code has  
> been written with this design in mind.

SOPE was never written with threading in mind, exactly the reverse is  
true (for async / multi process). And I still have the opinion that  
threading in appservers is more bad than good. Especially in  
combination with stateless apps like SOGo, which can be easily forked.

But I'm not opposed to accept SOPE thread safety patches. Of course  
the locks should be surrounded by proper #if SOPE_THREADs or something  
similiar, so that the locking stuff doesn't slow down single threaded  
apps.

Anyways, I've marked a lot of code sections which might need tweaking  
to work properly with threading. The comment usually has 'THREAD' in it.

> So I was wondering how functional it was?

I wouldn't expect it to work reliably, too many code section which  
need to be checked for thread safety (especially in multi CPU  
environments). It might _appear_ that it works, but the usual  
threading issues will crop up.

BUT: the error in your log isn't related to SOPE threading. It just  
shows improper setup of an NSThread (you forgot to setup the top level  
AR pool).

Greets,
(Continue reading)

Permalink | Reply | 4 comments |
headers
Wolfgang Sourdeau | 11 Dec 2008 20:54
Picon

Re: multi-threaded design in SOPE


> BUT: the error in your log isn't related to SOPE threading. It just 
> shows improper setup of an NSThread (you forgot to setup the top level 
> AR pool).

It's actually you, because it's done in SOPE.

-- 
Wolfgang Sourdeau   ::   +1 (514) 755-3520   ::   wsourdeau@...

--

-- 
OpenGroupware.org Developer
developer@...
http://mail.opengroupware.org/mailman/listinfo/developer
Permalink | Reply | 1 comment |
headers
Wolfgang Sourdeau | 11 Dec 2008 20:54
Picon

Re: multi-threaded design in SOPE


> SOPE was never written with threading in mind, exactly the reverse is 
> true (for async / multi process). And I still have the opinion that 
> threading in appservers is more bad than good. Especially in combination 
> with stateless apps like SOGo, which can be easily forked.

One argument in the favour of multi-threading is that the SOGo footprint 
in memory is huge: 176076 Kb of VSZ/16000 Kb of RSS on x86-64 when 
freshly started.

>> So I was wondering how functional it was?
> 
> 
> I wouldn't expect it to work reliably, too many code section which need 
> to be checked for thread safety (especially in multi CPU environments). 
> It might _appear_ that it works, but the usual threading issues will 
> crop up.

Thanks for your reply!

-- 
Wolfgang Sourdeau   ::   +1 (514) 755-3520   ::   wsourdeau@...

--

-- 
OpenGroupware.org Developer
developer@...
http://mail.opengroupware.org/mailman/listinfo/developer
Permalink | Reply | 1 comment |
headers
Helge Hess | 11 Dec 2008 21:20
Favicon

Re: multi-threaded design in SOPE

On 11.12.2008, at 20:54, Wolfgang Sourdeau wrote:
>> BUT: the error in your log isn't related to SOPE threading. It just  
>> shows improper setup of an NSThread (you forgot to setup the top  
>> level AR pool).
> It's actually you, because it's done in SOPE.

Ah, you are right, I fixed that.

Thanks,
   Helge
-- 
Helge Hess
http://helgehess.eu/
--

-- 
OpenGroupware.org Developer
developer@...
http://mail.opengroupware.org/mailman/listinfo/developer
Permalink | Reply | 0 comments |
headers
Helge Hess | 11 Dec 2008 21:52
Favicon

Re: multi-threaded design in SOPE

On 11.12.2008, at 20:54, Wolfgang Sourdeau wrote:
>> SOPE was never written with threading in mind, exactly the reverse  
>> is true (for async / multi process). And I still have the opinion  
>> that threading in appservers is more bad than good. Especially in  
>> combination with stateless apps like SOGo, which can be easily  
>> forked.
> One argument in the favour of multi-threading is that the SOGo  
> footprint in memory is huge: 176076 Kb of VSZ/16000 Kb of RSS on  
> x86-64 when freshly started.

It isn't an argument for threads. If you fork such a process, the OS  
will only actually copy memory pages which are changed by the child  
process. Top won't tell you about it, its super flaky to measure such  
things (and I don't know a better tool, Google might find some - well,  
the SOPE access-log tells you the actuall VSZ changes! If it increases  
with each request, you found a leak ;-).
The additional memory consumption should be the same like with  
threads. Minus all the hassle and slow downs.

Further: the 176MB VSZ should be mostly shared code? Shared bundles,  
shared libraries. Which of course are shared, so its quite reasonable  
(176MB sounds like shared libs with debugging symbols?)

Then 16MB RSS sounds reasonable per process, especially with 64bit?  
Probably could be optimized a bit further, but the ObjC runtime  
selector tables really become quite big in a large app like SOPE -  
probably twice as large with 64bit. I measured that a few years back  
(when 16MB was much :-)
But: its quite a big slow down in performance if you run the ObjC  
runtime multithreaded. So I would personally very much favor the 16MB
(Continue reading)

Permalink | Reply | 0 comments |

Gmane