From Newsgroup: comp.lang.tcl

Hi,

I've started reorganizing the old IOCPsock code I wrote about 20 years
ago and I would like to add some shared stuff in one file to the core.

https://github.com/davygrvy/iocpsock/blob/main/tclWinIocp.c

It isn't complete (by far) and will eventually include a test suite for
the lock-free FIFO queue routines.

Should I ask on tclcore mailing list?
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.tcl

Am 29.06.2026 um 21:46 schrieb David Gravereaux:

Hi,

I've started reorganizing the old IOCPsock code I wrote about 20 years
ago and I would like to add some shared stuff in one file to the core.

https://github.com/davygrvy/iocpsock/blob/main/tclWinIocp.c

It isn't complete (by far) and will eventually include a test suite for
the lock-free FIFO queue routines.

Should I ask on tclcore mailing list?

Hi David,
thanks for the great action. Well, we need it in fossil.

I can put this file into a fossil branch and open a ticket. But, on the
long run, it would be great if you could take care on fossil.

--- Other topic ---

You have perhaps seen the discussion yesterday on the exception channel proposal.
Your design was seen as superiour, but the ship sailed long ago.
Exceptions are reported be a read event and the read event should first
check for any exception/error.
To my knowledge, a socket connect error is reported by read and write
events and the program should first check
fcopfigure -error
for any exceptions.

Would that also be a feasable design for you?

Take care,
Harald
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.tcl

On 6/29/2026 11:55 PM, Harald Oehlmann wrote:

You have perhaps seen the discussion yesterday on the exception channel proposal.
Your design was seen as superiour, but the ship sailed long ago.
Exceptions are reported be a read event and the read event should first check for any exception/error.
To my knowledge, a socket connect error is reported by read and write
events and the program should first check
fcopfigure -error
for any exceptions.

Would that also be a feasable design for you?

No. Not for errors. That isn't the meaning of TCL_EXCEPTION. It is an alternate path like interrupts in GPIB, TCP urgent flag, QOS notices, etc
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.tcl

On 6/30/2026 3:17 AM, David Gravereaux wrote:

Would that also be a feasable design for you?

No.  Not for errors.  That isn't the meaning of TCL_EXCEPTION.  It is an alternate path like interrupts in GPIB, TCP urgent flag, QOS notices, etc

If I call Tcl_NotifyChannel(chan, TCL_EXCEPTION) in my Tcl_EventProc
after the prior Tcl_EventCheckProc, what handler does it run? None, as fileevent doesn't have "exception" as a valid event. All the pathways
are there. What I do with the TCL_EXCEPTION watchMask, and resultant
script it runs, is up to me

I already wrote the decoder for FLOWSPEC

/*
*----------------------------------------------------------------------
*
* DecodeQosFlowspec --
*
* Decodes the info from the QOS struct.
*
* Results:
* A Tcl_Obj* as a dict
*
* Side effects:
*
*----------------------------------------------------------------------
*/

Tcl_Obj *
DecodeQosFlowspec(QOS *qosPtr)
{
Tcl_Obj *dictPtr = Tcl_NewDictObj();

// Helper macro to clean up dictionary building
#define SET_DICT_INT(dict, direction, field, value) \
Tcl_DictObjPut(NULL, dict, \
Tcl_NewStringObj(#direction "_" #field, -1), \
Tcl_NewWideIntObj((Tcl_WideInt)value))

// Parse Outbound Flow Specification (Sending)
SET_DICT_INT(dictPtr, send, TokenRate, qosPtr->SendingFlowspec.TokenRate);
SET_DICT_INT(dictPtr, send, TokenBucketSize, qosPtr->SendingFlowspec.TokenBucketSize);
SET_DICT_INT(dictPtr, send, PeakBandwidth, qosPtr->SendingFlowspec.PeakBandwidth);
SET_DICT_INT(dictPtr, send, Latency,
qosPtr->SendingFlowspec.Latency);
SET_DICT_INT(dictPtr, send, DelayVariation, qosPtr->SendingFlowspec.DelayVariation);
SET_DICT_INT(dictPtr, send, ServiceType, qosPtr->SendingFlowspec.ServiceType);
SET_DICT_INT(dictPtr, send, MaxSduSize, qosPtr->SendingFlowspec.MaxSduSize);
SET_DICT_INT(dictPtr, send, MinimumPolicedSize, qosPtr->SendingFlowspec.MinimumPolicedSize);

// Parse Inbound Flow Specification (Receiving)
SET_DICT_INT(dictPtr, recv, TokenRate, qosPtr->ReceivingFlowspec.TokenRate);
SET_DICT_INT(dictPtr, recv, TokenBucketSize, qosPtr->ReceivingFlowspec.TokenBucketSize);
SET_DICT_INT(dictPtr, recv, PeakBandwidth, qosPtr->ReceivingFlowspec.PeakBandwidth);
SET_DICT_INT(dictPtr, recv, Latency,
qosPtr->ReceivingFlowspec.Latency);
SET_DICT_INT(dictPtr, recv, DelayVariation, qosPtr->ReceivingFlowspec.DelayVariation);
SET_DICT_INT(dictPtr, recv, ServiceType, qosPtr->ReceivingFlowspec.ServiceType);
SET_DICT_INT(dictPtr, recv, MaxSduSize, qosPtr->ReceivingFlowspec.MaxSduSize);
SET_DICT_INT(dictPtr, recv, MinimumPolicedSize, qosPtr->ReceivingFlowspec.MinimumPolicedSize);

#undef SET_DICT_INT
return dictPtr;
}


--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.tcl

And I kick off QOS "packets" with this

DWORD
PostOverlappedQOS (SocketInfo *infoPtr, BufferInfo *bufPtr)
{
int rc;
DWORD bytes = 0, WSAerr;

/*
* Increment the outstanding overlapped count for this socket.
*/
InterlockedIncrement(&infoPtr->outstandingOps);
bufPtr->operation = OP_QOS;

rc = WSAIoctl(infoPtr->socket, SIO_GET_QOS, NULL, 0,
bufPtr->buf, bufPtr->buflen, &bytes, &bufPtr->ol, NULL);

if (rc == SOCKET_ERROR) {
if ((WSAerr = WSAGetLastError()) != WSA_IO_PENDING) {
/*
* Eventhough we know about the error now, post this to the
* port manually, anyways.
*/

bufPtr->WSAerr = WSAerr;
PostQueuedCompletionStatus(IocpSubSystem.port, 0,
(ULONG_PTR) infoPtr, &bufPtr->ol);
}
} else {
/*
* The WSAIoctl completed now and is queued to the port.
*/
__asm nop;
}

return NO_ERROR;
}
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.tcl

On 6/30/2026 3:17 AM, David Gravereaux wrote:

TCP urgent flag

For WSAAsyncSelect, that's the FD_OOB trigger.

Tcl provides us the ability to manage these protocol specific incoming
things outside the normal read and write sides of a uni-directional communications link though TCL_EXCEPTION


time to fork
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.tcl

On 6/30/2026 4:18 AM, David Gravereaux wrote:

On 6/30/2026 3:17 AM, David Gravereaux wrote:

TCP urgent flag

For WSAAsyncSelect, that's the FD_OOB trigger.

Tcl provides us the ability to manage these protocol specific incoming things outside the normal read and write sides of a uni-directional communications link though TCL_EXCEPTION

Ok, the long winded reply...

Let's examine GPIB with its very important SRQ/RQS interrupts for how
devices on the bus tell the host (CIC) that something requires attention
with a status byte (STB) from the SPOLL that cleared the SRQ.

https://www.ni.com/en/support/documentation/supplemental/06/serial-polling-and-srq-servicing-with-ni-488-2-software-and-labv.html#section-392030912

"Because these bit definitions are not consistent among instrument
vendors, the method for determining the cause of a service request
varies with each device."

It might be the MAV bit in IEEE-488.2-1987 spec'd units, or a list of
many things that are usually device specific that require scripting.
For my pre-1987 spec'd Tektronix 5000 series plugins, MAV is bit 4, but
only when bit 7 is clear.

If I was to use the non-blocking calls for read/write, those would be
ibrda() and ibwrta() rather than the blocking Send() and Receive() in
the multidevice API.

https://linux-gpib.sourceforge.io/doc_html/reference-function-ibwrta.html

That would then make [read $gpib] and [puts $gpib {}] only initiate the
calls. I would have to retrieve the results of the operation through [fileevent $gpib read/write] after ibwait(..,CMPL) which has to be
serviced by a separate thread that eventually works its way through to Tcl_ChannelNotify(..,TCLREADABLE|TCL_WRITEABLE).

in this place, [fconfigure -error] is useful to let us know of the last operation and highly fits the model.

I really want all three.
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.tcl

Am 30.06.2026 um 19:44 schrieb David Gravereaux:

On 6/30/2026 4:18 AM, David Gravereaux wrote:

On 6/30/2026 3:17 AM, David Gravereaux wrote:

TCP urgent flag

For WSAAsyncSelect, that's the FD_OOB trigger.

Tcl provides us the ability to manage these protocol specific incoming
things outside the normal read and write sides of a uni-directional
communications link though TCL_EXCEPTION

Ok, the long winded reply...

Let's examine GPIB with its very important SRQ/RQS interrupts for how devices on the bus tell the host (CIC) that something requires attention with a status byte (STB) from the SPOLL that cleared the SRQ.

https://www.ni.com/en/support/documentation/supplemental/06/serial- polling-and-srq-servicing-with-ni-488-2-software-and- labv.html#section-392030912

"Because these bit definitions are not consistent among instrument
vendors, the method for determining the cause of a service request
varies with each device."

It might be the MAV bit in IEEE-488.2-1987 spec'd units, or a list of
many things that are usually device specific that require scripting. For
my pre-1987 spec'd Tektronix 5000 series plugins, MAV is bit 4, but only when bit 7 is clear.

If I was to use the non-blocking calls for read/write, those would be ibrda() and ibwrta() rather than the blocking Send() and Receive() in
the multidevice API.

https://linux-gpib.sourceforge.io/doc_html/reference-function-ibwrta.html

That would then make [read $gpib] and [puts $gpib {}] only initiate the calls.  I would have to retrieve the results of the operation through [fileevent $gpib read/write] after ibwait(..,CMPL) which has to be
serviced by a separate thread that eventually works its way through to Tcl_ChannelNotify(..,TCLREADABLE|TCL_WRITEABLE).

in this place, [fconfigure -error] is useful to let us know of the last operation and highly fits the model.

I really want all three.

David,

apparently, the use-case was not understood by the biweekly telco participants. Unfortunately, most don't read here and we require a
ticket or a TIP.

Could we copy all this to a RFE ticket on Tcl core?

Thanks for all,
Harald
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.tcl

On 6/30/2026 12:02 PM, Harald Oehlmann wrote:
...

Could we copy all this to a RFE ticket on Tcl core?

Sure, no prob. I don't know how things work now
--- Synchronet 3.22a-Linux NewsLink 1.2