I fixed a bug like this about 4 months ago, so it shouldn't be in the latest release. Can you download again, and tell me if you stil have problems.

Alternatively if you tell me which platform you use IGOR on (I'm guessing OSX) I can send you a beta copy of the latest version, which has a thread dedicated to incoming messages (rather than waiting for IGOR to give the XOP processing time).

hi andy,
i downloaded your package last week, so it should be the latest version.
I will be happy to try the new beta version.
My plateform is Mac OS X 10.5 INTEL.
do you need my email ?
luca

Please find attached a beta version of SOCKIT for OSX. Make sure you read the help file

There are a few major changes.
1) There is a dedicated thread in the XOP that reads messages from all the sockets. IGOR receives those messages when an IDLE message is sent to the XOP (which can be forced with the DoXOPIdle operation).
2) Several threadsafe functions are added to the XOP, which enable socket communication to take place from a dedicated IGOR thread. This method requires that the user deal with the incoming messages themselves (The SOCKITpeek function has to be used to collect the messages from the XOP, and the user is reponsible for tokenizing the data and doing any processing). Please see the help file for more details.
3) The processor function is no longer called if messages are received in reply to a send using the sockitsendnrecv operation. This is because placing sockitsendnrecv operations in the processor function was causing recursion in the XOP and causing IGOR to crash.

hi Andy,
i downloaded the beta version of SOCKIT but i am quite confused about the necessary changes to my experiment.

I never used Igor threadSafe functions and becoming an expert on Igor multiprogramming is beyond my actual goal.
Actually in the past few days i wrote an ObjectiveC application with a very little plotting support that satisfy my immediate needs.

If you have a skeleton experiment , with some already defined procedure using the new functions , that would save me a lot of time of try and error.
I realize that such an experiment will probably not works, but it would be a good trace.

thanks
luca

Hi Luca,
if you don't use the new functions the XOP works pretty similarly to how it used to. THis is because extra functionality has been added, none of the existing functionality was removed.
The only change that you will need to think about is if you use the SOCKITsendnrecv operation for synchronous send and receives.
Previously you would send a message and get a string back (if the other end sent one). The string that you received, as well as being available for your own use was also sent to the bufferwave AND the processor function for the socket (you may not have used the processor function).

The trouble was that if one also had a sockitsendnrecv operation in the processor function it was possible to get recursion occuring.

In this version the string that you receive back is still available for your own use. However it is no longer sent to the processor function.
If you don't use the sockitsendnrecv operation your code should work as before. If you do use the operation and a processor function exists for that socket number then you will need to consider how you use sockitsendnrecv.

Hi Andy,
the problem is solved and it was a mistake of mine with something similar to a pointer ...
It works with the standard and the beta version.
many thanks for your help.
luca