Re: [Oorexx-devel] RXAPI-exception: question on multithreading socket-app with OLE-instances ...

[Rony G. F. <Ron...@wu...>]

Hi there,

upon further investigation of the described problem it seems to be the=20
case that if multiple clients from the same machine connect to the same=20
server which serves them in different (ooRexx) threads, that *sometimes*=20
the socket function SockRecv() blocks forever. Setting the sockets to=20
non-blocking mode, ie. giving a value for SO_RCVTIMEO (and SO_SNDTIMEO=20
for that matter) it can be detected that a communication does not work=20
without blocking the app.

So the problem has nothing to do with creating an OLE object in threads,=20
but rather with connecting too many clients within a too short=20
time-frame to the same server socket. I could come up with an example=20
which would be able to demonstrate that effect, if that is helpful=20
(being wary, because it could also be the case that it is a problem that=20
may occur with sockets anyway and that one should expect and deal with).

Regards,

---rony



Rony G. Flatscher wrote:
> Hi there,
>
> trying to run an ooRexx socket (server) program using Kurt M=E4rker's=20
> TCP/IP framework which employes multithreading using "reply"=20
> statements in worker/listener threads.
>
> In a listener thread in that socket server program I am instantiating=20
> an OLE object (which is itself implemented as a WSC - Windows Script=20
> Component - file containing ooRexx and VBasic code) for each client=20
> and use its methods to serve a client connecting to the server.
>
> This works fine for the first client. The second client (to be served=20
> in its own thread) the instantiation of the OLE object does not work,=20
> instead it seems that the socket server thread waits for returning=20
> from .oleobject~new. Eventually, a Windows debug popup comes up=20
> (title: "Open Object Rexx Interface", displaying the Rexx icon)=20
> indicating that RXAPI has caused an access violaition (and asks to=20
> send the problem to Microsoft as well).
>
> Is there anything known about threading issues between sockets and OLE=20
> objects?
>
> ---
>
> In the meantime I tested another logic: the socket server program will=20
> instantiate the OLE class just once (using a class attribute to make=20
> it referrable from any thread of an instance of itself and sequencing=20
> the messages sent to it): this works for as many clients as one wishes=20
> reliably.
>
> So indeed there seems to be a multithreading issue here. Is there=20
> anything I could do to supply more information to help debug this, or=20
> is the report itself already enough?
>
> Regards,
>
> ---rony