httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From (Robert S. Thau)
Subject Re: Win32 Progress Report
Date Sun, 04 Aug 1996 16:22:58 GMT
  >   2) Dealing sfio --- this is probably best dealt with by simply
  >      moving to another stdio replacement which provides equivalent
  >      functionality and *is* preemption-safe, such as the hacked
  >      Berkeley stdio which comes with Chris Provenzano's pthreads
  >      package (which is therefore an obvious first target for such a
  >      port).

  Grrrk. You are depressing me. Is this really going to be any easier
  than safing sfio? Or, to put it another way, do you plan to make
  this change in the near future?

Well, like I said in private email, I've already largely done the work
to make such a switch *possible* (isolating really sfio-specific stuff
behind an interface which is more or less independant of the innards
of the package in question, and which also just *happens* to be
identical to a Berkeley stdio extension).  Hadn't planned on doing it
anytime soon, *except* as part of a port to a preemptive environment

As to whether this is harder or easier than safing sfio directly,
well, the advantage of using Proven's stdio is that you have to do
nothing to it to safe it, and strikes me that that can't be much
*harder* than actually doing *something* to sfio... that's really
all I was saying.  Apologies if I came off as being more alarmist.

As to safing sfio itself, it probably isn't that bad, but there are
potential race conditions in places you might not expect them, due to
such features as the sfio pool machinery (which unfortunately is in
play whether you want it to be or not), which would need careful


View raw message