Ian Timms wrote in a message to Craig Morrison:

IT> Just because the author chose to write it that way doesn't
IT> mean I have to agree with it, nor does it mean that I am
IT> trying to circumvent the operating system.

  If you are sticking your nose in where it doesn't belong, then you are
most definitely circumventing a built-in protection mechanism. SIO does
this, but it does this to provide a feature that is not present in the
stock COMM drivers that come with OS/2. Which is the ability to allow _DOS_
sessions to open a port that has already been opened by an OS/2 session.

IT> This mentallity of being the only user of every resource you
IT> open is something which needs to be stamped out if we are to
IT> truly multitask.

  You are putting words in my mouth sir.. I didn't say _every_ resource. I
said COMMUNICATIONS PORTS. Open files are a totally different story, there
are very good reasons for allowing more than one process to have access to
the same _file_. Granted, COMM ports are treated in much the same way as
files are, but there are distinctions.

  If I'm in the middle of transferring a 2.5 MB file over a long distance
link, or I am transferring vital financial statistics, I sure don't want
resource contentions for the port hosing the connection. COMM ports are NOT
meant to be shared resources. ONE process should monitor the port, that
process being the one that has active control over the port at that point
in time.

  We've got the ability to write multi-threaded applications under OS/2. We
as developers ourselves need to take responsibility for what we are doing.
I know for sure I don't want to let another process take on the
responsibility of making sure that my code is doing to the right thing. In
this scenario, if I let another process monitor the port, if something goes
wrong where do I look for resolution of the problem? Do I look at my code,
or do I attribute it to the other process? I'd much rather be able to say
with certainty that the problem was with my code where I can find it and
fix it, rather than chasing cheshire cats that disappear.

  Having a secondary process monitor a COMM port stinks badly of a DOS
mindset when it comes to programming. If the developer of the application
using the port can't start another thread to monitor the port in his
application, then maybe he should seriously think about taking up another
line of work.

    See ya,

Craig
cam{at}wpc.cioe.com


--- timEd/2-B9