xparace(3)

👑 XPARace — Race Conditions 💅

ok so this is xparace(3) from the SAORD Documentation XPA help pages, and bestie, we're talking about race conditions — the sneaky little gremlins of concurrent programming. let's get into it 🦋

---

✨ SYNOPSIS ✨

Potential XPA race conditions and how to avoid them. that's it, that's the whole vibe check.

---

💖 DESCRIPTION 💖

okay so here's the tea ☕ — currently, there is only one known circumstance in which XPA can get (temporarily) deadlocked in a race condition: if two or more XPA servers send messages to one another using an XPA client routine such as XPASet(), they can deadlock while each waits for the other server to respond. (this can happen if the servers call XPAPoll() with a time limit, and send messages in between the polling call.) 😭

the reason this happens is that both client routines send a string to the other server to establish the handshake and then wait for the server response. and since each client is waiting for a response, neither is able to enter its event-handling loop and respond to the other's request. it's giving two people both waiting for the other to text first, fr fr 💀. this deadlock will continue until one of the timeout periods expire, at which point an error condition will be triggered and the timed-out server will return to its event loop. slay, it escapes eventually.

---

🌸 avoiding it with XPA_IOCALLSXPA 🌸

starting with version 2.1.6, this rare race condition can be avoided by setting the XPA_IOCALLSXPA environment variable for servers that will make client calls. setting this variable causes all XPA socket IO calls to process outstanding XPA requests whenever the primary socket is not ready for IO. 👑

what that means in practice: a server making a client call will (recursively) process incoming server requests while waiting for client completion. it also means that a server callback routine can handle incoming XPA messages if it makes its own XPA call. iconic behavior honestly.

and there's a semi-public routine for toggling this on the fly:

oldvalue=XPAIOCallsXPA(newvalue)

you can use it to turn this behavior off and on temporarily. passing a 0 will turn off IO processing, 1 will turn it back on. the old value is returned by the call. 🫶

---

🙈 but why is it off by default?? 🙈

by default, the XPA_IOCALLSXPA option is turned off, because we judge that the added code complication and overhead involved will not be justified by the amount of its use. moreover, processing XPA requests within socket IO can lead to non-intuitive results, since incoming server requests will not necessarily be processed to completion in the order in which they are received. 😵💫 so like, the ordering goes sideways. noted.

---

🧚 the multi-process method 🧚

aside from setting XPA_IOCALLSXPA, the simplest way to avoid this race condition is to multi-process: when you want to send a client message, simply start a separate process to call the client routine, so that the server is not stopped. it probably is fastest and easiest to use fork() and then have the child call the client routine and exit. 💅

but you also can use either the system() or popen() routine to start one of the command line programs and do the same thing. alternatively, you can use XPA's internal launch() routine instead of system(). based on fork() and exec(), this routine is more secure than system() because it does not call /bin/sh. ✨ (yes, that's the glow-up, security-wise.)

---

🎀 the ack=false trick 🎀

starting with version 2.1.5, you also can send an XPAInfo() message with the mode string "ack=false". this will cause the client to send a message to the server and then exit without waiting for any return message from the server. this UDP-like behavior will avoid the server deadlock when sending short XPAInfo messages. no cap, it just fires and dips 🏃♀️💨

---

🌈 SEE ALSO 🌈

• See xpa(n) for a list of XPA help pages

---

and that's the whole page bestie, you're officially race-condition literate 💖 this lil manpage is from version 2.1.15, dated July 23, 2013, brought to you by the SAORD Documentation girlies. go forth and don't deadlock 🦋✨👑