Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > comp.os.msdos.programmer > #3973

Re: MSDOS 3.2 COM ports

From "R.Wieser" <address@not.available>
Newsgroups comp.os.msdos.programmer
Subject Re: MSDOS 3.2 COM ports
Date 2021-04-27 11:40 +0200
Organization Aioe.org NNTP Server
Message-ID <s68m63$o6s$1@gioia.aioe.org> (permalink)
References (6 earlier) <08aa84aa-2c84-4013-821c-67e04b7b4ceen@googlegroups.com> <s661tt$vvk$1@gioia.aioe.org> <d6ac0b06-f034-41fe-b9ec-c3d0fb525d10n@googlegroups.com> <s66d72$10j2$1@gioia.aioe.org> <91cf7f87-e2fc-4c94-bc1b-331c1c6085b2n@googlegroups.com>

Show all headers | View raw


Muta,

> A long-running "grep -R" running within PDOS, forget
> about the BBS, would be considered to be using
> blocking I/O (on the disk, not the BBS), wouldn't it?

Yes, and no.

No : As mentioned, on your own *local* machine you can most always use 
ctrl-c to abort (force-closing the program).

Yes : As long as your program doesn't output anything you cannot stop it 
(the ctrl-c checking is done inside (some of) the character output BIOS 
INTs)

> Interrupting either the disk or the BBS is an independent
> activity, isn't it?

And I'm not even going to try to answer this.   You're throwing apples and 
eggs together and expect a single explanation.

What happens on your local machine is one thing.
Your (client programs) communication with a server (the BBS) is another
How the server (your BBS) responds to your clients communication is a third.

Don't throw them all on a heap.    You're just end up confusing 
yourself.(and me for that matter)

And just ask yourself : Your BBS listens to your client-programs 
communications and does whatever it says.   How's that independant ?

> Are you talking about from an application programmer's
> perspective, a user's perspective, or something else?

both (though for different, opposite reasons), and what else is there ?

>> But keep the downside of it in mind.
>
> Can you list those? It might be possible to
> overcome them.

Whut ?  What didn't you understand from what I already said :

[quote=me, parent post]
But as your client program is using blocking I/O you could be pressing keys 
all you want, but those won't be send until after you got your response back 
from the BBS ...
[/quote]

Again: as long as you are in a blocking wait (for data to come in) *you 
can't do anything else*.  Your 'puter is effectivily frozen.    How do you 
think you can overcome that ?

Remark: if you can find a "wait for data *but use a time-out*" method you 
can mitigate /some/ of it - even though the user will still have the 
"pleasure" of experiencing freeze-stutter.   Not funny when you try to use 
the keyboard...

> I guess it depends on what we're trying to achieve.
>
> What would be a sensible achievement in your eyes?

And as far as I'm concerned ?     Anything.  As long as you learn from it it 
doesn't even matter if you can / will actually finish the program.     IOW, 
I consider the road traveled more important that arriving at the 
destination.

So yes, you can definitily create a client that uses blocking I/O to talk 
with a BBS.   No doubt about it.   And it will work well too.   It just has 
a certain behaviour not everyone might like ...

> BTW, I started this project in 1994.

I got my first PC a few years later : a 286 with turbo button (8 -> 12 MHz) 
:-)

Regards,
Rudy Wieser

Back to comp.os.msdos.programmer | Previous | NextPrevious in thread | Next in thread | Find similar | Unroll thread


Thread

MSDOS 3.2 COM ports "muta...@gmail.com" <mutazilah@gmail.com> - 2021-04-23 16:19 -0700
  Re: MSDOS 3.2 COM ports Grant Taylor <gtaylor@tnetconsulting.net> - 2021-04-23 18:26 -0600
    Re: MSDOS 3.2 COM ports "muta...@gmail.com" <mutazilah@gmail.com> - 2021-04-23 18:47 -0700
      Re: MSDOS 3.2 COM ports Grant Taylor <gtaylor@tnetconsulting.net> - 2021-04-23 20:08 -0600
        Re: MSDOS 3.2 COM ports "muta...@gmail.com" <mutazilah@gmail.com> - 2021-04-23 20:40 -0700
      Re: MSDOS 3.2 COM ports Grant Taylor <gtaylor@tnetconsulting.net> - 2021-04-23 20:14 -0600
      Re: MSDOS 3.2 COM ports "R.Wieser" <address@not.available> - 2021-04-24 10:07 +0200
        Re: MSDOS 3.2 COM ports "muta...@gmail.com" <mutazilah@gmail.com> - 2021-04-24 15:04 -0700
          Re: MSDOS 3.2 COM ports "R.Wieser" <address@not.available> - 2021-04-25 10:32 +0200
            Re: MSDOS 3.2 COM ports "muta...@gmail.com" <mutazilah@gmail.com> - 2021-04-26 01:32 -0700
              Re: MSDOS 3.2 COM ports "R.Wieser" <address@not.available> - 2021-04-26 11:42 +0200
                Re: MSDOS 3.2 COM ports "muta...@gmail.com" <mutazilah@gmail.com> - 2021-04-26 04:42 -0700
                Re: MSDOS 3.2 COM ports "R.Wieser" <address@not.available> - 2021-04-26 14:54 +0200
                Re: MSDOS 3.2 COM ports "muta...@gmail.com" <mutazilah@gmail.com> - 2021-04-26 14:10 -0700
                Re: MSDOS 3.2 COM ports "R.Wieser" <address@not.available> - 2021-04-27 11:40 +0200
                Re: MSDOS 3.2 COM ports "muta...@gmail.com" <mutazilah@gmail.com> - 2021-04-27 03:56 -0700
                Re: MSDOS 3.2 COM ports "R.Wieser" <address@not.available> - 2021-05-01 21:56 +0200
                Re: MSDOS 3.2 COM ports "muta...@gmail.com" <mutazilah@gmail.com> - 2021-05-01 14:36 -0700
                Re: MSDOS 3.2 COM ports "R.Wieser" <address@not.available> - 2021-05-02 10:29 +0200
                Re: MSDOS 3.2 COM ports "muta...@gmail.com" <mutazilah@gmail.com> - 2021-05-02 02:14 -0700
    Re: MSDOS 3.2 COM ports Peter 'Shaggy' Haywood <phaywood@alphalink.com.au> - 2021-04-28 14:15 +1000

csiph-web