DragonFly kernel List (threaded) for 2003-09
Re: Anybody working on removing sendmail from base?
06@xxxxxxxxxxxxxxxxxxxx> <20030927233131.4b3bd07c.cpressey@xxxxxxxxxxxxxxx> <3f76bb4a$0$268$415eb37d@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx>
Content-Type: text/plain; charset=us-ascii; format=flowed
X-Trace: 1064784028 crater_reader.dragonflybsd.org 267 220.127.116.11
Xref: crater_reader.dragonflybsd.org dragonfly.kernel:1327
Timothy Cava wrote:
> Chris Pressey wrote:
>> My thoughts are more about IPC. Generally, IPC under Unix (under most
>> OS'es actually) is a *mess*.
>> I *should* be able to write the statusbar program described above like:
>> done := false
>> wait for a message from (the clock|the disk|mbmon|my mbox)
>> if the message was...
>> that the time is now X:
>> my time := X
>> that the free disk space has changed to X:
>> my disk space := X
>> that the motherboard temperature is now X:
>> my temperature := X
>> that a message was delivered to my mbox:
>> increment my new-mail counter
>> that a message was read from my mbox:
>> decrement my new-mail counter
>> a request to terminate:
>> done := true
>> display (my time + my disk space + my temp + my new-mails)
>> until done
>> The thing is, I *can't* write it like this, mainly because the clock,
>> the disk, mbmon, and my mbox, aren't event-oriented - they don't work in
>> terms of sending and receiving messages; they mostly work in terms of a
>> synchronous system of "standard" input and output that is looking more
>> quaint every day. At best, I'd have to stitch together some sort of
>> Frankenstein's monster of signals and named pipes and kqueues and
>> polling. It *shouldn't* be this way.
>> In fact that's mainly why I'm here. I'm hoping it doesn't *have* to be
>> this way.
>> Will DragonFlyBSD allow me to write code like the above example? Is the
>> messaging abstraction intended to be solely for the benefit of the
>> 'guts' of the operating system, or will user programs be able to use it
>> as well - not just for writing more efficient code, but also more
>> *elegant* code? Perhaps a stickier question still - will I *ever* be
>> able to write code like this in a *portable* way...?
> Funny that you mention IRC. I'm currently writing a very modular console
> IRC client that has an ircii feel. ircii's codebase is horrible, but a
> lot of the functionality is good, so I've just written my own code.
> Everything is dynamic (windows, servers, numerics, etc). There's a
> TCL module, a perl module, yadda yadda. It's a usuable client at this
> point, other than DCC and robust key handling. I need to add things
> like loading an INVEX module when it sees that a server supports INVEX
> by parsing numeric 005, stuff like that. I want to make the key handling
> generic enough to have a vi module, where you type i<whatever><esc><a
> key to send>, or you can :%s/mstke/mistake, etc. Just for fun. :-)
> The screen handling is already generic enough that if somebody wrote a
> GTK module, you hook it to the screen parts on load and now you have
> your IRC output both on a console and in X11. The logging code is just
> on the screen stack, things like that. You can hook stdin in to the
> server_read stuff (my client uses libevent, which falls to kqueue) and
> type lines to see how the client reacts, this is good for looking for
> overflows or regression style things...
Whoa, IPC != IRC. Spaced...Ignore me.