Mail Archives: djgpp/1997/05/13/08:45:54
Jim Schwarz wrote:
> In pre-emptive multi-tasking, processes are run based on priority
Not necessarily true at all. The point is that in pre-emptive
multitasking the running process can be interrupted for another
to run. No priorities are needed, it can all be done in a
'round-robin' scheduler where all processes are run in order.
> The fact that co-operative multitasking can be mis-used, and
> tasks can hog the processor, is why LWP says bleh to it. It
> is also why Win3.1 is not a multiuser O/S. WinNT, UNIX/Linux
> and O/S2 are all multiuser O/S's and user some form of
> pre-emtive multitasking.
The last point is true but irrelevant. Pre-emptive multitasking
is not necessary for multi-user operating systems, if they are
designed properly, and it can be useful in a lot of single-
user systems. Win95 is also pre-emptive, but not multi-user.
> When a function is re-entrant it means it can call itself,
> without hosing up.
No, calling itself is recursion. Re-entrant means that it can
be called from different tasks without problems, even if it's
interrupted in the middle. For instance, many implementations
of printf aren't re-entrant because they form the strings in a
static buffer - if partway through it gets interrupted and another
task runs which also calls printf, the buffer will get the new
data and when the original task gets back the buffer will be
corrupted.
> > 6. Are there any plans to convert LWP into a normal library
> > (like libc.a and liballeg.a) or do I always have to link lwp.o
> > and lwpasm.o in with my programs?
>
> Not likely, unless it becomes an ANSI standard.
Huh? liballeg.a isn't an ANSI standard. Anyone can make a library
without it having to be any kind of standard. I tend to think that
with only two object modules there's not much point, but some people
like to have everything in libraries. Others prefer to have
everything as separate object modules. It's largely a matter of style.
> > 7. Are there any plans to convert libc.a to re-entrant code, so
> > that the modified header files are not needed?
>
> Again, not likely, unless it becomes a standard.
Again, nothing to do with standards. However, if libc is based
heavily on the gcc code (which I believe is the case) then it's
not going to get changed drastically unless the gcc maintainers
make it re-entrant (which IMO would be a good thing anyway). The
ANSI standard doesn't specify such things, nor should it, it isn't
concerned with local implementation issues.
There's nothing to stop someone producing a library with the fixes
in, to be linked before libc (or even merged with the new modules
replacing the old non-re-entrant ones).
Chris
- Raw text -