Re: [xml] win32 thread safety patch

----- Original Message -----
From: "Serguei Narojnyi" <serguein opencola com>
To: <xml gnome org>
Sent: Tuesday, January 15, 2002 2:02 AM
Subject: RE: [xml] win32 thread safety patch

My objection is to the thread-per-thread overhead.

Now it's obvious (now I'm a little more awake) that a cached
copy of the
pointer is needed, along with the thread HANDLE from
syncronisation. But
a thread-per thread approach is very wasteful, only one cleanup
should be needed.

the solution is very obvious, have some sort of protected queue. then
xmlGlobalStateCleanupHelperParams gets pushed down there from the
xmlGetGlobalState and there is some thread that checks that queue say
every 5 seconds or so and cleans up all stuff in queue for threads
that are
dead. i'll come around implementing it once i have some free time if
else wouldn't.

Thats a polled approach. What I was actually thinking was (pseudoish

HANDLE aMutex; /* protects the next three variables */
unsigned int threads = 0;
HANDLE *cleanuphandles; /* has 1 more entry than cleanupptrs - an Event
Handle */
void *cleanupptrs;

cleanupthread ()
  while (threads) {
    object = WaitOnMultipleObjects (cleanuphandles, INFINITY);
    /* grab aMutex */
    if (object == WAIT_OBJECT_0)
    else if (object > WAIT_OBJECT_0 && object < WAIT_OBJECT_0 + threads)

        docleanup (cleanupptrs[object - WAIT_OBJECT_0])
        removefromarray (cleanuphandles, object - WAIT_OBJECT_0,
        removefromarray (cleanupptrs, object - WAIT_OBJECT_0, threads)
    /* else if (object == WAIT_FAILED... */
    /* release aMutex */

I'll leave the queue addition/removal code as an exercise to the reader

This is better than a polled approach as it will stay completely
inactive until a new thread is added (and the Event is triggered), or a
thread quits.


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]