I'm fairly new to VxWorks OS and hence wouldn't mind explanations in case I differ in my understanding of things under the hood when they differ from more _traditional_ OSes like Linux and the likes. With that out of the way, let me begin my actual
question.

I am trying to create a loop-back test for testing changes I made to the serial UART driver on the board. Since I do not want to use a cross cable to actually short two UART ports externally, I've connected both of those ports to my dev machine. One
configured as an output port from the dev machine's perspective (and consequently as an Input port on the board) and the other an input port (an output port on the board). I am actually doing the loopback using a shared memory buffer which I am
protecting using a mutex. So there are two threads on the board, one of which reads from the input port, copies data to the shared memory and the other reads from the memory and sends it over the output port.

And I am using _regular_ open, read and write calls in my VxWorks application (by the way I _think_ it is part of the application code as I call the functions from `usrAppInit.c` not withstanding the fact that I can even call driver routines from here! (
Is it because of a _flat_ memory model vis-a-vis Linux?? Anyhow).

Now I these ports on VxWorks have been opened in a non blocking mode and here's the code snippet which configures one of the ports:

if( (fdIn = open(portstrIn, O_RDONLY | O_NOCTTY, 0) ) == ERROR) {
return 1;
}

if(((status = ioctl(fdIn, FIOSETOPTIONS, OPT_RAW))) == ERROR)
{
return 1;
}

/* set the baud rate to 115200
*/

if((status = ioctl(fdIn, FIOBAUDRATE, 115200)) == ERROR)
{
return 1;
}

/* set the HW options
*/

if((status = ioctl(fdIn, SIO_HW_OPTS_SET, (CS8 | 0 | 0))) == ERROR)
{
return 1;
}

And similarly the output port is also configured. These two are part of two separate tasks spawned using `taskSpawn` and have the same priority of 100. However what I am annoyed by, is that when I write to the in port from my dev machine (using a python
script), the read call on the board get's sort of _staggered_ (I wonder if that's the right way to refer to it). It is most likely due to the short availability of hardware buffer space on the UART input buffer (or some such). This is **usually** not
much of a problem if that is all I am doing.

However, as explained earlier, I am trying to copy the whole received character stream into a common memory buffer (guarded by a mutex of course) which is then read by another task and then re-transmitted over another serial port (sort of an in memory
loopback if you will)

In lieu of that aforementioned staggering of the read calls, I thought of holding the mutex as long as there are characters to be read from the Inport and once there are no chars to be read, release the mutex and since this is VxWorks, do an explicit `
taskDelay(0)` to schedule the next ready task (my other task). However since this is a blocking read, I am (as expected) stuck on the read call due to which my other thread never gets a chance to execute.

I did think of checking if the buffer was full and then doing the explicit task switch however if any of you have a better idea, I'm all ears.

Also just to see how this **staggered** read thing works from the perspective of the kernel, I timed it using a `time(NULL)` call just before and right after the read. So surprisingly, the very first chunk shows up a number, every other chunk after that (
if it's a part of the same data block coming from the outside) shows 0. Could anyone explain that as well?

Keen to hear

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)