Ian Alderman wrote:
Initially the concern is only for outbound notifications. However, there will be inbound notifications. For inbound the library canprovide an fd for DC to select() on so that any execution of Condor code by the library would be coming from a Condor controlled thread of control. The library would not call into any Condor code from a thread it controls.It seems to me that the library would need to be designed specifically with this in mind. For example, if the Condor controlled thread is reading from something or writing to it, what guarantees do I have that the library isn't also reading or writing to it? I think you'd need to provide lock and unlock functions to be called from within Condor to guard against this, or find some other way to synchronize -- in other words, the library would need to be designed to link against a single threaded application.
Yes. The input/output functions provided by the library can encapsulate any needed synchronization.
Have you discussed this with the authors/maintainers of the library? I can't imagine that this is the first time anyone's ever asked this.
I have, and they are going to provide us with such mechanisms.
Take a look at some of the GAHP implementations. I think we'd need a pretty similar interface. Or, as Todd implies, we could make a GAHP for the threaded messaging library.
There should be no need for a GAHP here, since we'll have support from the library itself.
Best, matt