Hi Sean,

There are thread libraries (go to www.freashmeat.net and search for
beowolf) that if the program is already SMP thread ready, a re-compile
with these libraries make them beowolf ready. They are extensions to
the messaging and forking routines.
Even though this technology is still under heavy development, if we make
sure that IB is thread safe over SMP, we will, by extension, make it
simpler for the beowolf ports.

I am not stating we should keep classic until the beowolf ports, just
keep it until we have thread safe superserver on SMP.

best regards

Dalton

"Leyne, Sean" wrote:

>
> Dalton,
>
> I don't agree.
>
> Support for thread management across servers ("beowolf type constructs")
> should NOT have any impact on the dropping Classic decision.
>
> Let's get IB running on server equipment and solving problems which
> exist in 90+% of the existing environments. The "beowolf" situation you
> describe falls well outside of this range, I would expect applies to
> less than 0.5% of cases (something like support for SCO).
>
> Finally, IB can't (and shouldn't) be all things to all
> people/users/developers. I have detected a tone running through a
> number of the postings lately which have tended to suggest otherwise.
>
> Sean
> -----Original Message-----
> From: Dalton Calford [mailto:dcalford@...]
> Sent: Tuesday, May 30, 2000 11:31 AM
> To: IB-Architect@egroups.com
> Subject: Re: [IB-Architect] SuperServer vs. Classic
>
> I personally would not want to see the classic version dropped until
> supersever supports threads that work across processors (and by
> extension accross machines in beowolf type constructs).
>
> best regards
>
> Dalton
>
> Jim Starkey wrote:
> >
> > At 12:44 PM 5/28/00 +1000, Jan Mikkelsen wrote:
> > >
> > >All this applies to superserver, of course. Classic should just be
> taken
> > >into the woods and shot.
> > >
> >
> > This is the single most difficult and important question facing future
> > development. Among the issues:
> >
> > 1. SuperServer only works on threaded platforms.
> > 2. Security is hopeless in Classic
> > 3. The conditionalization of the code makes ongoing maintenance
> > of two branches highly problematic.
> > 4. Support both on the same machine borders on impossible
> > 5. Given an abstract workload, neither is a clear winner.
> > Given a specific workload, one will generally outshine
> > the other.
> > 6. Asking the using at installation time which to install
> > time is problematic -- how could a new use possible make
> > an intelligent decision.
> >
> > An argument can me made -- but I haven't convinced Charlie -- that
> > removing Classic will speed up SuperServer (algorithms are now chosen
> > that work well in both), and that speeding up SuperService is
> necessary
> > to kill off Classic. Chicken, egg.
> >
> > Thoughts?
> >
> > Jim Starkey
> >
> >
> ------------------------------------------------------------------------
> > Failed tests, classes skipped, forgotten locker combinations.
> > Remember the good 'ol days
> > http://click.egroups.com/1/4053/4/_/830676/_/959696797/
> >
> ------------------------------------------------------------------------
> >
> > To unsubscribe from this group, send an email to:
> > IB-Architect-unsubscribe@onelist.com
>
> ------------------------------------------------------------------------
> Best friends, most artistic, class clown Find 'em here:
> http://click.egroups.com/1/4054/4/_/830676/_/959700578/
> ------------------------------------------------------------------------
>
> To unsubscribe from this group, send an email to:
> IB-Architect-unsubscribe@onelist.com
>
> ------------------------------------------------------------------------
> Find long lost high school friends:
> http://click.egroups.com/1/4056/4/_/830676/_/959703833/
> ------------------------------------------------------------------------
>
> To unsubscribe from this group, send an email to:
> IB-Architect-unsubscribe@onelist.com