Cheers,
Sh
Sh
> You are also going to get burnt by a long standing bug in XPCOM.
> CreateInstance is not thread safe in XPCOM and there is no way to avoid
> doing CreateInstance from multiple threads when you're an Apache module.
There is no multithreading in Apache 1.3.x, so you're clear for the
moment.
--
"Think of it this way: threads are like salt, not like pasta. You like
salt, I like salt, we all like salt. But we eat more pasta."
-- Larry McVoy
That is not true for the Windows versions of Apache 1.3.x, only the *nix
versions are process based.
In 2.0 both *nix and Windows can use any combination of processes and
threads. 2.0 is non-functional on the Win9x family and still has a lot of
issues on NT/2000. Apache 2.0 is not ready for general use yet.
--
Jon Smirl
jons...@mediaone.net
Thanks.
"Shalabh Chaturvedi" <sha...@india.com> wrote in message
news:97rb4v$i6...@secnews.netscape.com...
Microsoft has ASP+COM; Apache+XPCOM+Javascript is a very similar but
portable environment.
--
Jon Smirl
jons...@mediaone.net
Cheers,
Shalabh
Jon Smirl wrote in message news:98052e$pj...@secnews.netscape.com...
> It is fairly easy to make XPCOM work with Apache. Use the attached code as
a
> sample. Initialization is the tricky part since Apache will re-initialize
> your DLL and re-initializaing XPCOM does not work. This code is set up to
> avoid the problem rather than fixing it.
>
> You are also going to get burnt by a long standing bug in XPCOM.
> CreateInstance is not thread safe in XPCOM and there is no way to avoid
> doing CreateInstance from multiple threads when you're an Apache module.
My
> current work around is to load all XPCOM objects at init time. I then have
a
> method on each one that says clone me. I use this method at run time
instead
> of CreateInstance. This work around has the major drawbacks of needing to
> know all of the components up front, the special method, needing a wrapper
> for exisiting components, etc....
>
> The other scheme is to disable the threadsafe check macros in
CreateInstance
> and play Russian Roulette. This works most of the time. When it doesn't
work
> the Apache process restart feature will kick in and recover.
>
> --
>
> Jon Smirl
> jons...@mediaone.net
>
>
>
>
Yea that's the basic idea :-)
> For example I
> have a complex report that is generated by using a C++ database component
to
> retrieve and generate XML from a database. This XML is passed to another
> component a C++ XSL engine. The output of this is passed to a Java
> component, XML FOP, and turned into PDF. For other pages I use a
Javascript
> component to read the POST data and generate an HTML response.
>
> Microsoft has ASP+COM; Apache+XPCOM+Javascript is a very similar but
> portable environment.
Yes and something like an application server framework could be built out of
XPCOM. Just vapourware for now in my head. But I get all sorts of ideas
about publishing components that could publish html from data access
components (filesystem, flat file, object db, rdbms...) and also call
methods to update data in them. Also in the playground would be templating
components (that imlplement some templating language like asp, or php, or
webmacro), security managers and others.
Web applications could be built by writing business logic as a bunch of
XPCOM components (you could use C++, Python or JavaScript), using the above
core components and maybe other Webapp components. Plug and play data
stores, connect and create webapps, framework reuse, the works...!
Yes this is all very big but using it could start small first and grow fast
using Python rather than C++ components initially.
Shalabh
Perhaps you could spawn a worker thread to do the object creation for
you? Obviously all your objects would have to be thread safe too.
--
Adam Lock - lo...@iol.ie
BTW, a lot of the functionality you mention here has already been done using
Java though. See xml.apache.org. There is even a JavaScript framework called
Xang (I have been meaning to try)
I do see your point though.
Eric
"Jon Smirl" <jons...@mediaone.net> wrote in message
news:980loh$k...@secnews.netscape.com...
A much better fix would just be to fix CreateInstance. I have filed bugs on
the threadsafe issue. I have also looked at doing it myself but I don't feel
confortable mokeying around with a very core function in Mozilla.
--
Jon Smirl
jons...@mediaone.net
Doesn't say anything about XPCOM, just focuses on the apps using XUL. BTW, I
am the developer for the Jabberzilla client. For Moz to really be a
competator to .NET, it needs to have server apps.
Do you have your code posted somewhere? I have never seen it mentioned
before.
Eric
> I have recently tried (without success) to convice the Apache developers
on
> using NSPR for their run-time instead of building a new one (APR). Using
> NSPR would have made it possible to integrate Apache pools with XPCOM. It
> would also have allowed Apache modules to be replaced with XPCOM.
>
> As it stands Apache and XPCOM work are pretty indepenent of each other
> except for those few wrappers I supplied. I recommend using the NSPR
> functions from with XPCOM components behind Apache instead of the APR
> versions. Mixing APR and NSPR had threading complications on some
platforms.
>
> I attached a component written in Javascript that work with the PX7 module
> and Apache.
>
> --
> Jon Smirl
> jons...@mediaone.net
>
>
>
>
Jon Smirl
jons...@mediaone.net
Oh yeah, this would be quite a project. So you basically think it is not
worth the effort of pursuing, right now anyway?
Eric
"Jon Smirl" <jons...@mediaone.net> wrote in message
news:9838jd$l4...@secnews.netscape.com...
It is not necessary to merge Apache APR and XPCOM NSPR, it just would be a
lot more simple and efficient. You don't need to replace Apache modules with
XPCOM either, the code I posted eariler allow you to do that.
Another annoying issue is that there is no way to do local file IO from
XPCOM standalone without using the deprecated FileSpec object. This is
supposed to get fixed in nsLocalFile but it hasn't yet.
The reason I not posting is that a developer would need to be able to:
1) build XPCOM standalone
2) build the Mozilla Blackconnect extension
3) build Apache 1.3.x, sometimes module errors won't go to the console, you
have to debug with the error log
4) build XML Apache Xerces, moving target
5) build XML Apache Xalan, moving target
6) know how to write XSLT sheets
7) build zlib, libjpeg, libpng
8) use Java 1.3 SDk and build FOP
9) plus be able to work with my code
10) and I only have db interfaces up for ODBC and nothing on Linux, I'd like
to see a driver for the free Sybase 11.0.3
My system is a long ways from being an RPM.
If you are really interested I can send you some more components.
--
Jon Smirl
jons...@mediaone.net
I can do most of what is in your list there (and all with some extra free
time), but maybe there is someone out there who does have the super-skills
that really wants to work with it (I have limited time). Also, it could at
least be posted for future reference.
If you are interested, I can take care of most of the process for you.
Eric
"Jon Smirl" <jons...@mediaone.net> wrote in message
news:9844of$sk...@secnews.netscape.com...
Yes I've seen other projects at apache (not Xang though) and one of my main
motivations is to have a non-Java framework. Even most application servers
out there are Java only. And the non Java ones are either proprietary or
language-platform specific. XPCOM based would make something like this
language and platform independent.
Besides, I don't think any of the others got it _exactly_ right :-)
> I do see your point though.
>
> Eric
Cheers,
Shalabh
I think this is a great idea. If you're going to do this, count me in
already :-)
Shalabh
I abandoned Apache JServ/Tomcat for my current Apache/XPCOM set up. I ran
into serious performance problems using Java with core, complex things like
XSLT. Java performance starts off fine, it's ok up to a medium load, and
then falls apart at high loads. At high loads garbage collection was taking
35% of the CPU time which would make server response stall when it happened.
It's ok to have low load parts of the system in Java. I just had a problem
with the high load areas. C is also much more tunable. My current system is
almost 20x the speed of the old one. For example in Java you have limited
control of thread locks in things like memory allocation. In C I can use a
single threaded allocator if I know it is safe. Changing the allocator was
good for a 2x performance boost.
--
Jon Smirl
jons...@mediaone.net