[openbeos] Re: scheduler/reminder

  • From: "Adi Oanca" <e2joseph@xxxxxxxxxx>
  • To: <openbeos@xxxxxxxxxxxxx>
  • Date: Thu, 25 Sep 2003 00:50:14 +0300

From: "Lars Hansson"
> On Wed, 2003-09-24 at 17:22, Adi Oanca wrote:
> >     Exactly what you understand.
> Please explain what you mean. Do you mean a CLI app that runs
> continously in the background or one that is started/forked/spawned
> and then controlled by a GUI program?

    Both.

[from a previous email]
> >     Using a background CLI app in BeOS, is not quite like forking.
> What, exactly, do you mean by "Using a background CLI app"?

    My mistake! It is forking!

> >     As I said, short:
> >         * forking involves creating an new context for a new app( new
> > PROCESS, new userspace memory allocation(+mirroring original app space),
new
> > internal kernel data for that app(linked lists), etc.). processes
created by
> > fork don't finish execution when the main thread is done. If fact, I
don't
> > if there is a main thread OR, a team.
> >         * spawning only involves creating a new THREAD ( new, small,
> > internal data; NO memory allocation and no copying). They, by default
have
> > one feature that I really like: shared memory! Linux doesn't have that,
you
> > must use pipes for simple communication purposes.
>
> Linux threads has shared memory.

    Not hey don't! If I'm not wrong, there is a library that helps in that -
I don't know its name!

> >     Linux doesn't have threads! Yet!
>
> Linux has had kernel threads for years (since kernel 1.3.56 to be
> exact). Granted not as smooth to develop for as BeOS threads but threads
> nonetheless.

    Yes, you said right! KERNEL threads! There aren't USER threads!
    What can you do with kernel threads? Nothing! Only the Kernel uses them.
    Linux doesn't have user threads, at least until 2.6 is released.

[ me in a previous email]
Anyway, why use additional system resources( the
ones involving a new process ) when you can simply use a library in the same
space as you app. Because only small programs( exception: compiler IDEs) use
background CLI apps, why not use a small module with the same functionality?
They can surely be found on the net.

[/ me in a previous email]
> > > Because if there already is a standalone app that will get the job
done
> > > ,and your application isnt in need of the theoretical speed increase
> > > that using an addon would give, the right thing to do is to use the
> > > already existing CLI app.
> >
> >     Now, I think you are narrow-minded!
>
> If getting the job done efficiently and without re-inventing the wheel
> is narrow-minded then call me guilty.

    I DIDN'T said anything about reinventing the wheel. I gave you a choice
between CLI apps and modules.

[previous mail]
> >     How many apps depend on CLI programs?
> >     How may apps use modules to achieve a goal?
> >         I'd say... the majority! See... people know what's better!
> "The majority" is also using Windows, not Beos, so I guess Windows is
> much better than BeOS...
[/previous mail]
> >     I don't care the OS name, a fact remains a fact!
>
> It's not a fact just because you say it is.

    YOU ARE RIGHT! It's not just me who says that. It's "The Majority".


PS: When you're replying to an email make sure you're including the relevant
parts!!!

Adi.



Other related posts: