httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From ras...@madhaus.utcs.utoronto.ca
Subject Re: API question
Date Mon, 22 Apr 1996 12:38:01 GMT
> Hmmmm ... well to achieve intermodule connectivity the modules themselves
> don't need to know about threads - that would all be hidden in the buff
> library. The point is that a buff write by one module translates to a read
> by another - this is easy to hide using threads and the modules need never
> know it had happened. 

Intermodule connectivity may not require modules to be threaded, but if the
server process to which the module is linked is threaded then the module
itself and any library the module might use will definitely have to be
threaded.  I don't see any way around that.  Robert's pseudo-threading
may make this job a bit easier, but performance becomes a worry for me then.
After all, the biggest reason to move towards a threaded architecture is
performance, especially on heavily loaded systems.

For example, I currently link my module with the mSQL, Postgres95, GD, and
gdbm libraries along with a regexpr implementation.  The mSQL API library
stores a query result statically in its own memory and provides me with a
result cursor which I can then move through the data.  In a threaded server,
another thread can come along and allocate another result pointer which
my module has to be very careful about managing so it doesn't overwrite
the previous one.  Assuming of course that the mSQL library is written
well enough to allocate a new chunk of memory without overwriting the 
previous query.  There will definitely be race conditions to deal with
which should be handled by Robert's blocking mechanisms.  Completely
pre-emptive threading would be a nightmare for me.  Controlled threading
will be easier, but still quite involved for large modules.

-Rasmus

Mime
View raw message